R devel - Oct 2004 - Destructive str(...)?

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

Cheers,
Simon

[Tested with R 2.0.0 release (2004-10-04) on Mac OS X 10.3.5 - I have 
currently no other machine to test it on, but I very much suspect that 
this is platform-independent.]

the C code used to generate the object:

SEXP class, sref = R_MakeExternalPtr((void*) obj, R_NilValue, 
R_NilValue);
PROTECT(class = allocVector(STRSXP, 1));
SET_STRING_ELT(class, 0, mkChar("ObjCid"));
SET_CLASS(sref, class);
UNPROTECT(1);

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.

Brian

-- 
Brian D. Ripley,                  ripley@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595