Re: Some questions about GOOPS and CLOS in general

[Christian Lynbech <chl AT tbit.dk>]

>>>>> "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.

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.)


---------------------------+--------------------------------------------------
Christian Lynbech          | Ericsson Telebit A/S                       
Fax:   +45 8628 8186       | Fabrikvej 11, DK-8260 Viby J
Phone: +45 8628 8177 + 28  | email: chl@tbit.dk --- URL: http://www.tbit.dk
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic@hal.com (Michael A. Petonic)