RE: [Rd] str() resets class for environments

From: <Mark.Bravington_at_csiro.au>
Date: Fri 26 Nov 2004 - 12:16:42 EST


> : 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@csiro.au
> >



R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Fri Nov 26 12:23:26 2004

This archive was generated by hypermail 2.1.8 : Fri 18 Mar 2005 - 09:01:46 EST