On Sat, 30 Oct 2004, Prof Brian Ripley wrote:
On Fri, 29 Oct 2004, Simon Urbanek wrote:
I have encountered a strange behavior of the str function - it seems to modify the object that is displayed. Probably I'm using something unsupported (objects consisting just of an external reference), but
Yes, and I think it is documented somewhere, but I can't lay my hands on it right now.
still I'm curious as of why this happens. I create (in C code) EXTPTRSXP and associate a class to it via SET_CLASS. Such objects works fine until it's passed to str as the following output demonstrates:
> c<-.MCall("RController","getRController") > c [1] "<RController: 0x3be5d0>" > str(c) Class 'ObjCid' length 1 <pointer: 0x3be5d0> > c <pointer: 0x3be5d0> > str(c) length 1 <pointer: 0x3be5d0>
The .MCall basically produces an external reference and assigns a class (ObjCid) to it. There's a corresponding print method and it works fine. However, when str is called, it strips the class information from the object as a repeated call to str also shows:
> str(c); str(c) Class 'ObjCid' length 1 <pointer: 0x3be5d0> length 1 <pointer: 0x3be5d0>
Is this behavior intentional, undocumented or simply wrong?
The issue is almost certainly that something has forgotten/decided not to either set or respect SET_NAMED on the object, so when str does
object <- unclass(object)
or some such, the original object gets changed. Now the `something' has to be C code: possibly yours but probably something in R itself.
I think this is intentional. External references do not get copied, and the advice I recall is to wrap them in a list for use at R level (and before setting a class on them). In RODBC I took another tack, and attach the reference as an attribute to a `documentation' object.
str() probably ought to be more cautious when it encounters at external reference or similar exotic object, since it will look at list elements and attributes.
It's probably just unclass itself, not an issue with NAMED. External references are one of a handful of objects that are handled as references to mutable objects rather than as immutable values (the main other one being environments). unclass is destructive when applied to a reference object. At some point it might make sense to make unclass signal an error when used on a reference object, and clean up the things this breaks, including str and a number of other print methods. On the other hand, the same issue exists with all attributes on referece objects, so the safest approach is to use a wrapper as Brian suggests.
luke
-- Luke Tierney University of Iowa Phone: 319-335-3386 Department of Statistics and Fax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: [EMAIL PROTECTED] Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
______________________________________________ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
