On 7/5/06, Thomas Lumley <[EMAIL PROTECTED]> wrote:
> On Wed, 5 Jul 2006, Gabor Grothendieck wrote:
>
> > On 7/5/06, Thomas Lumley <[EMAIL PROTECTED]> 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
