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

Re: A question

Well it is more code but...

Based on your explanation below, I have some questions:

1. Would (does) the compiler optimize away the function call for the
   getter/setter functions (as I assume it does for class slots)?

2. Does d2c implement subclass slots?  I also find them essential.

3. Doesn't your suggestion create potential symbol table name conflicts
   between class slots with the same name but from different classes?

In any case, when I discovered what seemed to me to be a basic feature
was missing, I assumed there would likely be other deficiencies, and did
not want to invest the time as a result.

I don't think you can argue that class slots are an obscure feature,
even if there is an alternative way of doing them.

I also don't think you can make the generalization that class vars are
not common.  I use them all the time (whenever all the instances of a
class share the same attributes) which is often.

> 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.
>
References: