[Rd] attributes of environments

Gabor Grothendieck ggrothendieck at gmail.com
Wed Jul 5 18:39:59 CEST 2006


On 7/5/06, Thomas Lumley <tlumley at u.washington.edu> wrote:
> On Wed, 5 Jul 2006, Gabor Grothendieck wrote:
>
> > On 7/5/06, Thomas Lumley <tlumley at u.washington.edu> wrote:
> >> On Tue, 4 Jul 2006, Gabor Grothendieck wrote:
> >>
> >> > In the code below, e is an environment which we copy to f and then
> >> > add attributes to e.  Now f winds up with the same attributes.
> >> >
> >> > In other words it seems that the attributes are a property of the
> >> > environment itself and not of the variable.  Thus it appears we
> >> > cannot have two environment variables that correspond to the
> >> > original environment but with different attributes.
> >>
> >> No, we can't. The two variables are references to the same environment, so
> >> they are the same.
> >>
> >> If you want the attributes to be copies rather than references then create
> >> a list with the environment as an element and put the attributes on the
> >> list.
> >
> > I realize that that is how it works but what I was really wondering was
> > should it work that way?
> >
>
> I think it really should (and this question has come up before).  If you
> do
>    e<-environment()
>    f<-e
>
> then there is only one object that f and e both point to. Now, since such
> things as S3 class and matrix dimension are implemented as attributes I
> think you really have to consider the attributes as part of the object
> [which is also how they are implemented, of course].  So if e and f are
> the same object they should have the same attributes.

I don't think this follows since in the other cases modifying the
object also creates a copy.

>
> Another reasonable position would be to disallow attributes on
> environments (as we do with NULL, another reference object), but that
> seems extreme.

I don't think that that would solve it because there is still the issue
of the class attribute which you can't disallow.

In fact consider this:

e <- new.env()
f <- e
class(f) <- c("myenv", "environment")
F <- function(x) UseMethod("F")
F.environment <- function(x) 1
F.myenv <- function(x) 2
F(e) # 2
F(f) # 2

The point is that subclassing does not work properly with environments
yet subclasses of the environment class should be possible since R
is supposed to be OO and I see no valid reason for exclusing environments
for this.  I guess in this discussion I am coming to the realization that
this issue really is a problem with the current way R works.



More information about the R-devel mailing list