[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CLOS, and slot hiding.
- To: kempf@Sun.COM
- Subject: Re: CLOS, and slot hiding.
- From: email@example.com (firstname.lastname@example.org any day now)
- Date: Fri, 8 Apr 88 08:41 est
- Cc: email@example.com, firstname.lastname@example.org, sidney@XX.LCS.MIT.EDU, email@example.com
- Comments: NOTE %acorn@oak... WILL BECOME @GOLD-HILL.COM ANY DAY NOW
Date: Wed, 06 Apr 88 09:30:08 -0700
>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
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
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
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.