Re: Some questions about GOOPS and CLOS in general

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

Per Bothner <per@bothner.com> writes:

> Mikael Djurfeldt <mdj@mdj-pc.nada.kth.se> writes:
> 
> > (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.)
> 
> Ah, I see; we're not talking about a CLOS-like system at all.

Well, "CLOS-like" is a relative term, but you're right that it is
fundamentally different.  I'm not sure exactly which difference you
reacted to.

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

An error should be generated on an attempt to add an access method for
a slot to an accessor if an access method for a different slot in the
same class and with the same name already has been added.
(This occurs when 1. class C2 has a non-merged slot S with accessor A and
 class C1 has a slot S with accessor A and 2. C2 inherits from C1 and
 3. C1 and C2 both are defined in the same module.)

> > 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.
> 
> Ugh.  The "class precedence list" is an ugly concept to start with.

:) Yes.  However, the behaviour is not entirely nonintuitive.  It is
the "most specific" slot which is selected akin to the selection of
virtual methods in C++.  (I actually meant "well defined" rather than
"consistent".)

> How about allowing anonymous slots?  If you do not specify a slot name,
> you get a hidden name, perhaps one generated using gensym (but that should
> be an implentation detail).  The idea is that you would not be able to
> access the slot using slot-ref, only with accessor functions, and that an
> anonymous slot is never merged with any other slot.

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.