Re: CLOS, and slot hiding.

[mike%acorn@oak.lcs.mit.edu (mike@gold-hill.com any day now)]

    Date: Mon, 04 Apr 88 08:34:59 -0700
    From: 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 the package system is really the only way to do this, then there
is really a deep flaw in CLOS. It doesn't support classes for
data-abstraction very well at all. Was this issue every discussed
in the design of CLOS? 

I would like to submit this as an official comment on the draft CLOS
spec (88-002) for x3j13. The class abstraction should support this
kind of information hiding. The names of the instance variables
should not be automatically inherited by the subclasses in every
case. One must at least be able to override this default behavior and
specify that certain instance variables are specific to the class and
thereby avoid the name conflict problem with instance variables of
subclasses.

    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.

I want to use the SAME name, i.e. identical package, etc.
Using a separate package is unacceptable, as the package namespace in
common lisp is a GLOBAL space. Gensymming symbols and gensymming packages
seem like the same solution to me, both equally "tricky".
    
    >What I really want to be able
    >to do is define instance variables whose names are local to the
    >specific superclass.


...mike beckerle
Gold Hill

P.S.,
  
   I really should give credit to marty hiller (ariel@oz) for 
this observation about CLOS instance variables. She passed it
on to sidney who passed it on to me.