[Rd] str() resets class for environments

[Mark.Bravington at csiro.au]

> : Henrik Bengtsson:
> : > : I am curious though, do you not run into problems by 
> setting and getting
> : > : attributes on environment in 'mvbutils'? The example of 
> John Chambers I
> : > : re-posted, which shows that attributes can (will?) get 
> "killed by 
> operating
> : > : on the [environment] object "locally" in a function", 
> suggests that you
> : > : will.
> : > : 
> : > 

In my code, I do want to permanently set the "global" attributes of an environment such as pos.to.env(1) from within a function, so the behaviour of [in effect] 'attr<-.env' is not at all problematic :)

[In old versions of R, I used to have to invoke a function called 'lib.fixup' after setting an attribute of a search path environment, to make sure it "really happened", but this has been unnecessary in recent versions.]

> :Peter Dalgaard <p.dalgaard <at> biostat.ku.dk> writes:
> : Environments are already irregular in that they are never duplicated
> : (which is what causes these issues in the first place). External
> : pointers have the same feature, and Luke Tierney has suggested that
> : they perhaps should be wrapped in an object with more normal
> : semantics. Perhaps we should consider doing likewise with
> : environments? 
> 
> Gabor Grothendieck <ggrothendieck <at> myway.com> writes:
> To me that would make sense in keeping the rules of the language
> more consistent.  The mvbutils example suggests that it also has
> uses in addition to regularity and additional ones may come to
> light too.
> 

If environments were wrapped, would it still be possible to change the attributes of e.g. pos.to.env (5), as opposed to the attributes of a copy? That's the feature I'm keen to retain. For example:

> e5 <- pos.to.env( 5)
> attr( e5, 'my.attr') <- 'whatever'
> # If 'e5' is a wrapper, then this will no longer change the attribute of 'pos.to.env( 5)'
> attr( pos.to.env( 5), 'my.attr')
NULL
> # So I would need to be able to do something ugly like this:
> pos.to.env( 5) <- e5  # Yuk!?

Wrapping environments does avoid the "top level" of nonduplication, but the deeper level of nonduplicating the contents is unavoidable (and that's the point, of course): 

> pos.to.env(5)$x
NULL
> e5$x <- 0
> pos.to.env(5)$x
[1] 0

So I'm not sure all this can ever be made entirely "clean", even if automatic wrapping did get used. Equally, though, I'm not sure I've correctly understood the intention.

Incidentally, 'pos.to.env(5)$x <- 0' results in "Error: Target of assignment expands to non-language object". Should I have expected that?

BTW sorry about Outlook's mangling of the lines & indents-- at least, I presume it's Outlook's fault.

Mark

> > *******************************
> > 
> > Mark Bravington
> > CSIRO (CMIS)
> > PO Box 1538
> > Castray Esplanade
> > Hobart
> > TAS 7001
> > 
> > phone (61) 3 6232 5118
> > fax (61) 3 6232 5012
> > Mark.Bravington at csiro.au
> >