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> [EMAIL PROTECTED]
[1] 5
R> [EMAIL PROTECTED]
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 [EMAIL PROTECTED] <- 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)
> [EMAIL PROTECTED]
[1] 5
> [EMAIL PROTECTED]
Error: no slot of name "b" for this object of class "foobar"
> attr(foobar, "b") <- 10
> [EMAIL PROTECTED]
[1] 10
> [EMAIL PROTECTED] <- 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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
