[Rd] str() resets class for environments

[Gabor Grothendieck]

Henrik Bengtsson <hb <at> maths.lth.se> writes:

: 
: > -----Original Message-----
: > From: r-devel-bounces <at> stat.math.ethz.ch 
: > [mailto:r-devel-bounces <at> stat.math.ethz.ch] On Behalf Of 
: > Mark.Bravington <at> csiro.au
: > Sent: Wednesday, November 24, 2004 1:43 AM
: > To: hb <at> maths.lth.se
: > Cc: r-devel <at> stat.math.ethz.ch
: > Subject: RE: [Rd] str() resets class for environments
: > 
: > 
: > 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.
: 
: Then I agree with you that it should not be made defunct; in general, if
: there is a rational for using a feature in R and if someone relies on it,
: then I believe one should be careful and consider alternatives before
: removing it. I hope I did not break your code now by bringing it up to the R
: core team.
: 
: 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.
: 

The Chambers example simply shows what can happen now -- not what should
happen.  The real question is what should happen.    If all objects
can have classes and attributes and if environments are objects then
it follows that environments should be able to have classes and
attributes too.  If the language is to be made irregular in this
respect then there needs to be a very good reason and none has
been put forth, at least in this thread.