Re: [Rd] attributes of environments

From: Gabor Grothendieck <ggrothendieck_at_gmail.com>
Date: Wed 05 Jul 2006 - 16:39:59 GMT

On 7/5/06, Thomas Lumley <tlumley@u.washington.edu> wrote:
> On Wed, 5 Jul 2006, Gabor Grothendieck wrote:
>
> > On 7/5/06, Thomas Lumley <tlumley@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.



R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Thu Jul 06 03:53:15 2006

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.1.8, at Wed 05 Jul 2006 - 20:35:07 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-help. Please read the posting guide before posting to the list.