Luke Tierney <[EMAIL PROTECTED]> 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 ~~~~~~~~~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 ______________________________________________ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
