From ggrothendieck at gmail.com  Wed Jul  5 22:33:25 2006
From: ggrothendieck at gmail.com (Gabor Grothendieck)
Date: Wed, 5 Jul 2006 16:33:25 -0400
Subject: [Rd] attributes of environments
In-Reply-To: <44AC1E8D.4000602@stats.uwo.ca>
References: <971536df0607042012h43eb1581n418e9cddfe3a51bb@mail.gmail.com>
	<Pine.LNX.4.64.0607050911380.32591@homer22.u.washington.edu>
	<971536df0607050939r11dbdb93g6186550477e78d92@mail.gmail.com>
	<Pine.LNX.4.64.0607050947290.32591@homer22.u.washington.edu>
	<971536df0607051016m3ad69f53j3c97ccebf759781d@mail.gmail.com>
	<5062E054-F56C-42AA-A446-BC53628DC189@r-project.org>
	<971536df0607051123p6f0eaf6chc9e50cfc72b0fe51@mail.gmail.com>
	<44AC110B.90306@stats.uwo.ca>
	<971536df0607051247p7f30412bs45c6cf81dfc16949@mail.gmail.com>
	<44AC1E8D.4000602@stats.uwo.ca>
Message-ID: <971536df0607051333s51010444vecb09453717413c2@mail.gmail.com>

On 7/5/06, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
> On 7/5/2006 3:47 PM, Gabor Grothendieck wrote:
> > On 7/5/06, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
> >> On 7/5/2006 2:23 PM, Gabor Grothendieck wrote:
>
> >>  I think by this time I have shown that subclassing of
> >> > environments does not work yet it could if it were designed differently
> >> > and furthermore there are significant problems with the workarounds.
> >>
> >> I don't think you've shown that subclassing of environments doesn't
> >> work.  You have an example that shows that shows that R implements
> >> Henrik's "Case 2" rather than his "Case 1", but as Thomas and I said,
> >> that really has nothing to do with subclassing.
> >>
> >> Subclassing is about defining a new class, not about copying objects.
> >> You can (and did!) define a new class which inherits from the
> >> environment class.
> >
> > But by subclassing in the way allowed one comes up with something that
> > is not useful.
>
> You haven't shown that.  Show an example where you define a new class
> that should inherit from environment but doesn't.
>
> All you've shown so far is that when you try to change the class of an
> object to a new class, it appears that the class of another object also
> changes.  (The explanation being that they are really just different
> names for the same object.)

But that is not how oo works.  When one defines a child its a
delta to the parent.  It does not change the parent.

Your parenthesized statement discussed why it works that way
under the current design but that is not inevitable.  The current
design is not the only possibility.

>
> > That is why tcltk and Henrik's package wrap environments in lists and define
> > a completely different class but by doing that they are not able to take
> > advantage of inheritance.
>
> I think they did that because they wanted explicit references to
> objects, rather than the built-in implicit ones.  I've wanted explicit
> references to things on a number of occasions too, but that's really
> unrelated to inheritance as far as I can see.

They are defining environments with special features yet they can't make
use of inheritance as they injected the environment object into their object
rather than subclassing it -- understandable given the current limitations.



[Rd] attributes of environments
Gabor Grothendieck