Re: Some questions about GOOPS and CLOS in general

[Mikael Djurfeldt <mdj AT mdj-pc.nada.kth.se>]

Christian Lynbech <chl@tbit.dk> writes:

> >>>>> "Mikael" == Mikael Djurfeldt <mdj@mdj-pc.nada.kth.se> writes:
> 
> Mikael> This means that a programmer need to be aware of what slots are used
> Mikael> by the class libraries he use in his program.
> 
> I am not quite sure I see the problem. If we are talking instance
> slots, what could be gained from having two slots of the same name?
> 
> Class slots (which are not :each-subclass allocated) are of course
> somewhat different, but presumably the documentation of such slots
> should be a vital part of the library specification.
> 
> Gregor Kiczales has written a nice paper about how to work with the
> concept of libraries within the framework of something as powerfull as
> CLOS. I can dig up a reference if needed.

Here's the most grave version of the problem:

Class B in module B inherits class A in module A.

Class A has a slot a which is exported.

(When designing and using class libraries there is a rule not to access
slots from an imported class using `slot-ref/set!' but using accessors
instead, so, in our example, module B imports the accessor function a
from module A.)

The implementor of A needed a state variable in his implementation.
He chose to call this non-exported slot x.

The implementor of B knows that A has a slot a, since a should occur
in the specification of A and certainly occurs in the interface of
module A.  So he won't chose the name a for any of the "local" slots
he need.  It happens that he needs a "local" state variable in his
implementation and he choses the name x.

In the current version of GOOPS, STKlos, and, if I've read the CLOS
manual correctly, also in CLOS, the system does not generate an error.
The error will (hopefully) be discovered the day when the
"independent" pieces of code in A and B start to interact through the
slot x...

This causes the nastiest form of bugs if you don't include a list of
*all* slots, even "fixed-in-next-release-foobar", in the library spec,
and you don't want to do that, because that will unconditionally lead
to people starting to use those slots.

(I truly hope that there is something which I have misunderstood
 here.  Could all of you CLOS-guys verify what I'm saying above?)

I presume that the article you are referring to is "Issues in the
Design and Specification of Class Libraries"
http://www.parc.xerox.com\
/spl/groups/eca/pubs/papers/Kiczales-OOPSLA92/for-web.pdf

The paper touches upon the problem by stating the rule "No portable
class CP may inherit, by virtue of being a direct or indirect subclass
of a specified class, any slot for which the name is a symbol in the
default user package."

If I have understood this correctly, which I hope I haven't, this
seems to be a pretty lame attempt to work around the problem.

What we really want above is that there are two slots with the name x,
one belonging to A, and one belonging to B.

If we are using `slot-ref/set!' to refer to slots (thus breaking the
rule of class library design and use) this causes a problem.

However, if we use the accessor x, there is no problem, since the
module A will contain the accessor referring to A's x while the module
B will contain a different accessor function, referring to B's x.

In order to get consistent behaviour from `slot-ref/set!' one could
specify that the name is always referring to the slot of that name
occurring first in the class precedence list.

We could also introduce a new slot option #:name (similar in spirit to
#:keyword) by which it is possible to introduce extra names for the
slot.  (x #:name 'A:x) would make it possible to say
(slot-ref o 'A:x).

Finally, you will be able to specify #:inheritance #:merge which says
that if the the class and its direct subclasses contain slots with the
same name, their slot definitions will be merged in a way similar to
CLOS.

There will also be a possibility to use the MOP to define a new
metaclass <CLOS-style-class> (or whatever) where #:merge is the
default #:inheritance for all slots.

> * The class X inherits features from two unrelated classes piano and bike.
>   (I don't have a better example at the moment :>)
>   Both classes A and B export a feature with the name "pedal".
>   How can X access the feature "pedal" inherited from piano *and*
>   the feature "pedal" inherited from bike?

> Mikael> I have a plan to fix this in a way which is compatible with STKlos: I
> Mikael> intend to introduce slot classes and extend the meta object protocol
> Mikael> in a way that we can choose whether to merge slots or allow multiple
> Mikael> slots with the same name.  The default will be not to merge.  If you
> Mikael> are useing the STk compatibility module, the default will be to merge.
> 
> I could be confused about what you mean by "slot classes", but are you
> planning to do something different than what real CLOS is doing? (In
> CLOS, slot merging is handled through generic functions 'compute-slots'
> and 'compute-effective-slot-definition' which are part of the MOP.)

I hope that GOOPS will become real as well.  :)
(There is of course still work to do before it has aquired a stable
 shape.)

I'm referring to metaobjects which will be used by
effective-slot-definition-class to create the class of the
<effective-slot-definition>.  The <effective-slot-definition> will
contain the basic information actually used by the system when
accessing slots.

There will be a slot option #:class by which the user can specify a
<slot-definition-class> for a slot.  It will provide default values
for slot options.  There will also be a new slot
'default-slot-definition-class in <class>.  This will implement the
actual mechanism by which you can create <CLOS-style-class> mentioned
above.


I'd like to add that although all of this may seem complex, it is in
fact beautiful and, again, it will *increase* efficiency of slot
access at the same time that it provides greater flexibility.