Re: CLOS, and slot hiding.

[kempf@Sun.COM]

>I would like to be able to define a class that has certain advertised
>behavior that I can advertise to users who will use it as a superclass
>of their own defined classes, as a mixin. All I need to advertise are
>the names, calling sequences and effects of some methods. As far as I
>can tell, CLOS requires me to also advertise the names of the instance
>variables that the methods use internally to contain state, so that
>users can avoid name collisions when they define their own instance
>variables.

There are a couple of considerations here. Slots with no declared
accessors will not be accessable to the outside world via access
generic functions. One way to achieve encapsulation is to not declare
accessors. This still leaves WITH-SLOTS, but if you don't want the
slots to be accessable through WITH-SLOTS, just don't export their
names from the package in which the class is defined. If you subclass,
it should not matter what you name the slots as long as the names are
in a different package. When resolution of slot names occurs, you will,
of course, get slots with names that are the same except for the package,
but since putting something in a different package is usually an indication
that it is functionally distinct, this should not matter to the structure
of the program. In this manner, you should not have to use gensym's or
other tricks to be sure that no name collisions occur.

>What I really want to be able
>to do is define instance variables whose names are local to the
>specific superclass.

In summary, by not making slots accessable through access functions
and using the package system to isolate the names in the package
where the superclass is defined, you can achieve this.

			jak