CLOS, and slot hiding.

[mike%acorn@oak.lcs.mit.edu (mike@gold-hill.com after 1-April-88)]

This query came in from sidney marcowitz in our GOLDWORKS development
group re: CLOS.  I think it raises an important issue. Defstruct has
the exact same problem, and I had hoped that CLOS would improve upon
it in this area. The only discussion I find of this is page 1-13 of the
new spec (88-002) which indicates that slots can be shadowed, but
it seems to imply that if not shadowed they cannot be hidden.

...mike beckerle

Gold Hill Computers


----------------------------------------------------------------------

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.

For example, say I define a moving-object class that when included as
a superclass provides methods for things like update-velocity. It
should be transparent whether the internal representation uses
cartesian or radial coordinates. But people who define classes that
inherit from the moving-object class will have to know not to name any
instance variables X and Y, or RAD and THETA, or whatever. Even worse,
I can't change the internal representation of my moving-object class
without the danger of creating collisions with names that my users
have happened to choose. Using macros that create gensyms for the
instance variables, or defining a new package for each such
superclass, or choosing long ugly names that nobody will ever think
of, all seem like unaesthetic solutions. What I really want to be able
to do is define instance variables whose names are local to the
specific superclass.

This is a problem with the specification's support of data
abstraction, modularity, and information hiding. What I would like to
know is if CLOS addresses the problem, and if not, are there specific
reasons that the CLOS committee has for leaving it out of the spec. 

Thanks,

-- sidney