[Rd] Destructive str(...)?

[Peter Dalgaard]

Luke Tierney <luke at 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 at biostat.ku.dk)             FAX: (+45) 35327907