Destructive str(...)?

Luke Tierney <luke@stat.uiowa.edu> writes:

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.

Argh. I think this means that there is a bug in the tcltk code since
tclObj class objects are exactly external references with a class
attribute. It doesn't seem to have bitten anyone yet, though. Or were
you saying that we should fix str() instead?

Anyways, Tcl objects do provide a rather nice illustration of why
reference objects are non-duplicatable (which is the reason behind
unclass being destructive). They have a finalizer that decrements the
Tcl reference count when the R object is destroyed. To avoid bad
things resulting from decreasing the refcount multiple times,
duplication would require an increment of the reference count, and R
just isn't geared to do that: we'd need to introduce something like an
R_RegisterCDuplicator function.

O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907