Re: Some questions about GOOPS and CLOS in general

[Mikael Djurfeldt <mdj at thalamus dot nada dot kth dot se>]

Mikael Djurfeldt <mdj@mdj-pc.nada.kth.se> writes:

> Per Bothner <per@bothner.com> writes:
>
> > > 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.
> >
> > Do any any of them even have the concept of "local" slots?  Could they?
> > I don't think it make sense in the context of methods not being
> > associated with classes, but with generic functions.  C++, Java, Simula,
> > or Smalltalk could sensibly have a "local slots" concept;  CLOS cannot.
>
> Given the change I describe (allowing multiple slots with identical
> names), GOOPS can.  As long as you keep the accessor functions
> separate, there's no problem.

When you extend functionality supplied by a class library using
inheritance, you can think of the implementation as layered:

                  Instance	Accessors	Operations
		  +--------+
button      	  |x	   |	x  (1)		POSITION
		  |y	   |	y		DRAW
------------------|--------|------------------------------------------
		  |TEXT    |	TEXT		DRAW (new method)
text-button	  |x	   |	x  (2)
		  +--------+

(Names exported from the module are written with upper-case letters.)

The implementation of button has two "local" slots x and y, but
the interface specifies POSITION as the way to query about the
position of the button.

A programmer now wants to re-use the button library to implement a
text-button.  The interface doesn't specify that the instance contains
slots x and y.  He uses a new slot x to represent the x offset of the
text within the button.

There is no problem with this since the accessors x (1) and x (2) are
two different generic functions.  x (1) is not exported from the
button module, so there will be no name collision.  Generally, there
will be no risk of collisions of names because the implementor of the
text-button library knows what names are used in the interfaces of the
libraries he uses.

Also, the system is intuitive: Each layer of the design contributes
its own accessors and operations.

In the text button library, a new method specializes DRAW to the
text-button.  Here both layers use the same generic function since, in
both cases, we are dealing with the same concept: how to draw.  x (1)
and x (2) above represent conceptually different things, the x
position and the x offset of the text, so it is natural that x (1) and
x (2) are different generic functions.

The responsibility of administering names is left to the module
system.  If we use text-buttons together with an object from another
library which also has a slot TEXT with accessor TEXT, we use the
renaming capability of the module system to avoid name collision.

> Or we might remove `slot-ref/set!' entirely (or, rather, deport them
> to the stklos compatibility module) and by default generate an
> accessor for the slot.  (With the error condition mentioned above,
> this should not become a problem.)
>
> We could introduce the slot option
>
>   #:default-accessor NAME
>
> to give a different name if we want that.
>
>   #:default-accessor #f
>
> would mean not to add any default accessor method.

I think this is a good idea myself, but I had expected reactions to
this.  Since no people have complained, I might actually go about
removing slot-ref and slot-set! in release 0.1.4.