> : 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 > > [EMAIL PROTECTED] > > ______________________________________________ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
