[Prev][Next][Index][Thread]
Re: Need help with Class-Allocated Slots
In article
<Pine.GSO.3.96.1000629115446.4116H-100000@tardis.tardis.ed.ac.uk>, Hugh
Greene <q@tardis.ed.ac.uk> wrote:
> 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
> >
> > 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 :-)
Thanks! I did what could to shine the light of truth on the sinners in
Gamorrah...yup...
> 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".
"The difference between theory and practice is that in theory, there is
no difference, but in practice, there is."
Practical is nice. But Dylan already handles methods and singletons
differently than Java, why not this too? And, actually, I wonder why
the author of the JOOP article specifically wanted class slots to have
that syntax. Did the article say?
One reason could be that it seems more intuitive to those from a
C++/Java background. But as I said,
> > It's really the same principle as Dylan's singletons. You can make
> > as many instances of a singleton as you like. It's just that all
> > those instances refer to the same object. Similarly, you can make
> > as many instances of a class slot as you like, they just all refer
> > to the same object.
Since I *do* come from a C++ background, both threw me. But once I
figured out the rationale, it made perfect sense. Anyway, if we allow
class slots to 'be' part of the class itself, we should similarly allow
all slots of a singleton class to be 'part of' the class itself (i.e.
treat all of a singleton's slots like class slots) to prevent mismatched
concepts.
Note that I quoted 'be' and 'part of'. That's because class-accessed
class slots (can anyone think of a good phrase for this concept?) amount
to syntactic sugar, like the dot and assignment syntax.
> > 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.
Well, let's keep things like that to a minimum. I'm more comfortable
with dot syntax for class slots as "syntactic sugar" than as "how the
language actually works", if you take my meaning.
As syntactic sugar, we'd be free to ignore the <class>.slot syntax. If
it was how the language worked, well, it'd be a) unavoidable and b) a
hack.
> > 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.
[snip]
> 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).
I have no problem whatsoever with compilers that recognize this idiom
and optimize it.
On the other hand, I really don't like messing with standards. Sure,
it's not handed down from above, but the authors had sound theoretical
reasons for writing it they way they did:
1) If you think it through, like I did, it reinforces the concept that a
class really is just a plain-jane instance of <class>, like any instance
of any variable. Adding class-accessible class slots makes a <class>
special...
2) ...and special cases should be kept to a minimum.
But again, a compiler that recognizes the idiom and optimizes it is okay
by me, but it shouldn't be in the standard.
Follow-Ups:
References: