This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Some questions about GOOPS and CLOS in general
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.