[Rd] slot(obj, "nosuch") documentation question

[John Chambers]

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
>
>