I noticed the following today --- str() seems to remove any extra
class information added to an environment.
> e <- new.env()
> class(e)
[1] "environment"
> class(e) <- c("foo", class(e))
> class(e)
[1] "foo" "environment"
> str(e)
Classes 'foo', 'environment' length 0 <environment>
> class(e)
[1] "environment"
I'm not sure if this is related to the external pointer issue
mentioned in the NEWS file. Is this the intended behavior for
environments? (It happens in today's R-devel also.)
> version
_
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status
major 2
minor 0.1
year 2004
month 11
day 15
language R
>
-roger
--
Roger D. Peng
http://www.biostat.jhsph.edu/~rpeng/
On Tue, 23 Nov 2004, Roger D. Peng wrote:> I noticed the following today --- str() seems to remove any extra class > information added to an environment. > >> e <- new.env() >> class(e) > [1] "environment" >> class(e) <- c("foo", class(e)) >> class(e) > [1] "foo" "environment" >> str(e) > Classes 'foo', 'environment' length 0 <environment> >> class(e) > [1] "environment" > > I'm not sure if this is related to the external pointer issue mentioned in > the NEWS file.It is. Needed essentially the same fix.> Is this the intended behavior for environments? (It happens > in today's R-devel also.)I believe the intention is that you should not class environments. Luke suggested earlier that unclassing one be made an error, and I have now done that. Note that environments are not copied, and so everything you do to one instance you do to all other instances of it. Setting a class makes little sense for such an object. -- Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
Henrik Bengtsson wrote:> Should attr()<-, attributes()<-, > class()<- give an error when applied to an environment? I see > no reason why > not.It would break the workspace-organization code in the 'mvbutils' package, which relies on being able to set and unset attributes of environments on the search path (specifically, the 'name' and 'path' attributes). So personally I'd much prefer not to have this happen! For the wider R community, I'm not sure how many users the 'mvbutils' package has, but I think it's a fair number judging from emails I get. If you do feel the extra security is vitally important, perhaps there could be 'lock.attributes' and 'unlock.attributes' functions for environments. The idea would be that each environment has an invisible (i.e. internal) mock-attribute "locked", which would be TRUE by default (on creation of the environment). While "locked" is TRUE, any attempt to muck about with the environment's attributes would cause an error. But if you really did need to change attributes of that , it would still be possible by calling 'unlock.attributes' first. 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
> : 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)$xNULL> 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 > >