Paul Roebuck wrote:> Using slot() on object (or "@") and using a nonexistent
> slotname returns an error (see example code).
>
> R> setClass("foobar",
representation=list(a="numeric"))
> [1] "foobar"
> R> foobar <- new("foobar", a=5)
> R> foobar at a
> [1] 5
> R> foobar at b
> Error: no slot of name "b" for this object of class
"foobar"
>
> The details section of manpage has a paragraph that
> seems to agree with above:
>
> Unlike attributes, slots are not partially matched,
> and asking for (or trying to set) a slot with an
> invalid name for that class generates an error.
>
> But then the last paragraph in that same section seems to
> suggest otherwise.
>
> Currently the @ extraction operator and slot function
> do no checking, neither that object has a formal class
> nor that name is a valid slot name for the class. (They
> will extract the attribute of the given name if it
> exists from any R object.) The replacement forms do
> check (at least if check=TRUE).
>
> Are these two paragraphs not in partial conflict with each
> other?
No, but a little more detail in the documentation would have been
helpful. See my previous thread on this list: the methods
documentation is getting a major rewrite at the moment.
What's guaranteed is that foobar at b <- 1 will be disallowed if
"b" is
not a valid slot name or the right hand side is not coerceable to the
appropriate class. So as long as nobody cheats, only valid slot names
will be found and not finding a slot of an invalid name generates an error.
However.
For various reasons, slots in R were implemented as attributes, and in
the immediate future seem likely to remain so. And, for now, there is
no guarantee that code has not gone around assigning attributes with
other names.
The access function @ or slot() doesn't go off to the class definition
to check the name, so once such an attribute is inserted, it looks like
a "slot". But you still will get an error assigning a value, because
that computation _does_ check validity. All this is in pursuit of
efficiency, arguing that slot access tends to happen more often than
replacement.
The following extension of your example illustrates:
> setClass("foobar", representation=list(a="numeric"))
[1] "foobar"
> foobar <- new("foobar", a=5)
> foobar at a
[1] 5
> foobar at b
Error: no slot of name "b" for this object of class "foobar"
> attr(foobar, "b") <- 10
> foobar at b
[1] 10
> foobar at b <- 1
Error in checkSlotAssignment(object, name, value) :
"b" is not a slot in class "foobar"
> I had initially expected (my initial bottom-up
> quick glance only read last paragraph) to get NULL from
> invalid slotname.
>
> This is in reference to writing method that might be
> passed an object created by previous version of software,
> and new slots were added to class in later revisions.
>
> For such situations, is the norm then to do
> "slotNames(obj) %in% <slotname>" prior to accessing any
> slotname from extended class?
>
Dangerous practice. I presume what happens is that objects are saved,
then restored after the class has been redefined. Restoring the old
object creates an invalid object of the class. You really should follow
the restore by "fixing" any out of date objects.
It would be nice if R had versioning software that did some of this
automatically, although in general it's a tough problem.
Perhaps other users who have encountered the problem of revising classes
might comment on what their practice is. Managing changing class
definitions is an interesting and important topic.
John>
> TIA
>
>
> R version 2.7.0 Patched (2008-06-04 r45830)
>
> ----------------------------------------------------------
> SIGSIG -- signature too long (core dumped)
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>