Skip to content

str() resets class for environments

5 messages · Mark Bravington, Henrik Bengtsson, Peter Dalgaard +1 more

Original
Mark Bravington
#
Henrik Bengtsson wrote:

            

      
      
      
    

        
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
    

    

      
      #
    

  


  

          

      
      
      
    

        
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.

Cheers

Henrik

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    
1 day later

    

      
      

        


  

        

      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.

  
  


  


      

    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

      
Gabor Grothendieck <ggrothendieck@myway.com> 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
    

    

      
      #
    

  


  

      
Peter Dalgaard <p.dalgaard <at> biostat.ku.dk> writes:

: 
: Gabor Grothendieck <ggrothendieck <at> myway.com> writes:
: 
: > : 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.
: 
: 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? 

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.