[Prev][Next][Index][Thread]
Re: Need help with Class-Allocated Slots
On Wed, 28 Jun 2000, Dustin Voss wrote:
> In article <m3zoo8p02k.fsf@soma.andreas.org>, Andreas Bogk
> <andreas@andreas.org> wrote:
>
> > "Scott McKay" <swm@mediaone.net> writes:
> >
> > > During the design of Dylan, I proposed that class slots be
> > > accessible by calling the accessor on the class object itself, but
> > > Moon didn't like it because it confuses class vs. instance. I agree
> > > with Moon on the exact point, but I still think that the semantics
> > > of my dumb-ass proposal are well enough understood, that it is
> > > probably reasonable.
> >
> > Maybe it's time to resurrect the Dylan Language discussion at
> >
> > http://www.isr.com/dylan/dylan-language/
> >
> > I agree that it should be possible to access class slots without
> > having an instance.
> >
> > Andreas
>
> I'm actually surprised this is even being considered. The idea that
> class slots belong to the class itself is incorrect, though widely held.
Good exposition but I have to disagree :-)
IMHO, as a philosophical point, I'd say that, as long as an idea is
consistent in itself and its context, it's not "incorrect"; it may well be
"useless" or "unpopular", though ;-) In particular, the JOOP article I
quoted yesterday specifically wanted "my" behaviour from languages instead
of "yours".
> Each class is an instance of <class>. Conceptually, the lines
>
> -------------------------------------
> <my-class>.my-class-slot;
> my-class-slot-getter (<my-class>);
> -------------------------------------
>
> imply that <my-class> has a slot called my-class-slot. But it doesn't!
> <my-class> is an instance of <class>, not a sub-class of <class>. ...
You're right here. In terms of Dylan's half-hidden meta-object protocol
(MOP), this proposal is in effect allowing you to create subclasses of
<class>. (Simplistically, one new subclass for each such instance of
<class>.) We'd presumably still want to keep <class> as a sealed class,
so there'd have to be some "magic" here. However, there's already "magic"
involved in creating things like limited types, so I don't mind that.
> Do y'all really want to muddy up Dylan's pristine conceptual waters like
> that? (It really is much more pristine in my head than in English.)
No :-) I think things are conceptually still clean, just a bit more
powerful. Concretely there'd be this extra bit of magic but, as I say,
I'm happy with that.
> Of course, it is certainly possible. You could write an getter that
> specializes on a particular instance of the class, like so:
>
> -------------------------------------
> define method my-class-slot-getter (an-instance :: <class> == <my-class>)
> an-instance.my-class-slot;
> end;
> -------------------------------------
>
> But I'd rather have the pristine waters, thank you.
More to the point, you can already do something like this
----------------------------------------------------------------
// This module variable is *not* exported.
define variable *my-class-slot* = #f;
// This method is exported.
define method my-class-slot (an-instance :: <my-class>)
*my-class-slot*
end;
// This method is exported.
define method my-class-slot-setter (new-val, an-instance :: <my-class>)
*my-class-slot* := new-val
end;
----------------------------------------------------------------
so I'd prefer to be able to do this cleanly and perhaps more efficiently
(given the compiler may be able to do more magic if this "pattern" is in
the language and hence known to it). The each-subclass case is worse,
because the simplest implementation would be to use a hash table keyed by
the class, making slot access O(log(N)) instead of O(1).
Just my 50 cents :-)
Hugh
Follow-Ups:
References: