[Prev][Next][Index][Thread]

Re: A question

At 4:49 PM -0500 1/12/00, rwk@americom.com wrote:
>I went to try Gwydion and the first thing I needed was "class slots"
>which d2c does not yet implement, so I gave up quickly.  (Class slots
>seem rather fundamental and essential to me as I have never written an
>application which does not require them).

You gave up too quickly.  There is no significant semantic difference
between the following:

--------- class slot -------

define class <foo> (<object>)
  class slot bar = init-bar();
end

--------- no class slot --------

define class <foo> (<object>)
end

define variable *bar-storage* = init-bar();

define method bar (x :: <foo>)
  *bar-storage*;
end

define method bar-setter (v, x :: <foo>)
  *bar-storage* := v;
end


------------

Note that I don't consider the global variable a significant difference
because its scope can be tightly limited via modules.  (In fact, fairly
find-grained control of scoping of global variables like these was
one of the goals of the module system.)

Back when I was still involved in the design of Dylan I argued that it
would be a simpler and better language if it had instance slots.  Period.

For example, class slots are really just a mechanism for implicitly
defining a global storage location with associated accessor methods,
which just duplicates defining a global variable (as in my example above)
and methods which return and set its value.  I don't think class slots
occur often enough to really warrant the addition of a special mechanism
to the core language when an existing mechanism serves equally well.
[Obviously, some people disagree with me, since class slots are still
part of the language, in spite of my preferences.]

The specification of virtual slots was at one time a complete mess, with
a lot of effort going into an attempt to clean it up (not entirely
successfully if I remember correctly).  That effort could have been used
much more productively elsewhere by just flushing virtual slots.
[Again, some people disagreed with me, though I think this one was much
closer (and hence wasted a lot more discussion time because it was
"controversial").]

all-subclass slots are the only variant I thought had some merit, as it
is probably easier for the implementation to make this efficient (perhaps
via a metaclass that adds the appropriate slot to the classes) than it
is for a user to write similarly efficient code (probably via a global
variable containing a <table> keyed on the class).  What all-subclasses
is really doing is providing a little bit of what one might expect to
get from a metaobject protocol.
Follow-Ups: References: