Re: CLOS, and slot hiding.

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

    Date: Wed, 06 Apr 88 09:30:08 -0700
    From: kempf@Sun.COM
    
    >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 think you have this backwards. The flaw (if any) is not in CLOS but
    in Common Lisp. The charter of the CLOS committee was to design an
    object-oriented extension to Common Lisp, not to "fix" Common Lisp.
    Common Lisp deals with modularity using name spaces, packages being
    one method of establishing a name space. If the extension were to
    Scheme, then environments would be used for establishing the modularity
    needed for data abstraction. Extending any language for object-oriented
    programming requires that the fundamental abstraction principles of
    the language be used and compatibility extended, otherwise the extension
    becomes unworkable.

I don't think that common lisp has any particular flaw in this area.
To separate global objects, like specvars, you have to 
use packages. Local variables and functions can be separated using
lexical closures.

My dispute is with the nature of instance variables. In the current
CLOS proposal, they get treated in a manner more analogous to
CL's special vars than to local variables. You have to use symbol
naming at the user level to separate them, i.e., either gensymming 
or packages. 

    You want to use the same name but have it mean something different? I'm
    confused, sorry. Do you have an example? 
    

Here's a simple one. Everything described here is in the same package.

I have a class, MOVING-OBJECT, with two instance vars RHO and THETA, 
used by the method MOVE, defined for MOVING-OBJECT as an update to
the RHO and THETA vars.

I tell my associates about the class MOVING-OBJECT, and the method
MOVE.  He defines a subclass AIRPLANE. He wants to use the method
MOVE on instances of AIRPLANE, but he also wants to define methods
BANK and TURN, involving tilting and turning of the conceptual
airplane with respect to level. He wants to use instance variables
RHO and THETA to represent angles of tilt and turn.

He cannot use these names because the class MOVING-OBJECT already
has these names. Unfortunately, since he didn't need to know the
implementation of the MOVE method, he didn't know that there 
were already instance vars named RHO and THETA.

Note that the desired behavior is not like CLOS's "local" slots, but
might be called "class specific" slots. These slots exist in
all instances of the class and subclass, but their names are
available only to methods defined on the specific class that
they are created in.

...mike beckerle