Skip to content

The class attribute on an environment seems buggy (PR#2159)

4 messages · Henrik Bengtsson, Peter Dalgaard, John Chambers

Original
Henrik Bengtsson
# 
Full_Name: Henrik Bengtsson
Version: 1.6.0, 1.5.1
OS: WinXP Pro
Submission from: (NULL) (128.250.252.82)


The following example, which I tested on both R v1.5.1 and R v1.6.0 on WinXP
Pro, shows the problem I encountered when trying to use the class attribute of
an environment:

# Define method print() for class Environment
C

print(e)
# gives:
# [1] "An Environment!"

# Exit [R]
q(save="yes")

When restarting [R] and loading the previous workspace something goes wrong(?):
% R

print(e)
# gives:
# <environment: 01BE52F4>
# attr(,"class")
# [1] "Environment"

print(class(e))
# gives: 
# [1] "Environment"

print(unclass(e))
# gives:
# <environment: 01BE52F4>
# attr(,"class")
# [1] "Environment"

str(e)
# gives because of the malfunctioning unclass():
# Class 'Environment' Class 'Environment' Class 'Environment' Class
'Environment' 
# Class 'Environment' Class 'Environment' Class 'Environment' Class
'Environment' 
# Class 'Environment' Class 'Environment' Class 'Environment' ...

Note how unclass(e) does not work properly. More importantly, it the
S3/UseMethod() method dispatching get confused and won't recognize the class
attribute. 

Cheers

Henrik Bengtsson

Home: 201/445 Royale Parade, Parkville
Office: Bioinformatics, WEHI, Parkville
+61 (0)412 269 734 (cell), +61 (0)3 9387 791 (home), +61 (0)3 9345 2324 +(lab)
hb@maths.lth.se, http://www.maths.lth.se/~hb/
Time zone: +10h UTC (Sweden +2h UTC, Calif. -7h UTC)


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._
John Chambers
# 
Any attribute of environments, not just the class, can be killed by
operating on the object "locally" in a function.

Example:

R> f <- function(x){ y <- x; attr(y, "foo") <- NULL; y}
R> ev <- new.env()
R> attr(ev, "foo") <- "bar"
R> ev
<environment: 0x8b515d4>
attr(,"foo")
[1] "bar"
R> f(ev)
<environment: 0x8b515d4>
R> ev
<environment: 0x8b515d4>

The reason is that the C routine `duplicate' does not duplicate an
environment  OR its attributes.

I was bitten by this trying to use environments as reference objects in
the Omegahat OOP package.

Would there be a problem with a "fix" in which the environment was left
unduplicated, but environments with attributes are "duplicated" by
creating a copy of the attribute list, but with the copy still pointing
to the same environment?

If that is not possible, it would be good to have another datatype that
had roughly those properties.  Otherwise, it's difficult to build on
this datatype in designing new classes.

(The same issue applies to other types, such as external pointers.)
hb@maths.lth.se wrote:

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

      
John Chambers <jmc@research.bell-labs.com> writes:

            

      
      
      
    

        
I've been wrapping such environments in lists, as in

            

      
      
      
    

        
function (init = "") 
{
    n <- evalq(TclVarCount <- TclVarCount + 1, .TkRoot$env)
    name <- paste("RTcl", n, sep = "")
    l <- list(env = new.env())
    assign(name, NULL, envir = l$env)
    reg.finalizer(l$env, function(env) tkcmd("unset", ls(env)))
    class(l) <- "tclVar"
    tclvalue(l) <- init
    l
}

where the list(env = new.env()) construct is to avoid sticking a class
directly on "env". 

What you're suggesting would seem to have the same effect, i.e. the
environment gets effectively embedded in a structure on which you can
set attributes. It does sound like it could work.

I'm just a little worried whether it would be clear enough to the end
user what is going on, or whether we'd just be compounding problems of
duplications that don't duplicate...

BTW, this was never a bug...

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      John Chambers
    

    

      
      #
    

  


  

      
Peter Dalgaard BSA wrote:

            

      
      
      
    

        
For class-related work, embedding in a list (yes, I do that too) has
somewhat the wrong message, because now the object appears to extend
"list", whereas the intended model is that it extends "environment".

The distinction isn't all academic, because one would like to avoid
list-style computations for "[", etc, which are pretty much guaranteed
to cause trouble.

            

      
      
      
    

        
My personal need is for something that acts as a reference (aka
database, object table, etc.)  The understanding is that setting named
elements in this object works as for a reference--all copies see the
changes.  If the object can otherwise behave in standard "S language"
semantics, programming will be more straightforward.

For now, I use a list containing an environment, but eventually
something more direct will likely be needed.

            

      
      
      
    

        
OK, but as Henrik's mail suggested, users get unpleasant suprises from
trying to treat environments as ordinary objects.