[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CLOS, and slot hiding.
- To: email@example.com (firstname.lastname@example.org any day now)
- Subject: Re: CLOS, and slot hiding.
- From: kempf@Sun.COM
- Date: Wed, 06 Apr 88 09:30:08 -0700
- Cc: kempf@Sun.COM, email@example.com, sidney@XX.LCS.MIT.EDU, firstname.lastname@example.org
- In-reply-to: Your message of Tue, 05 Apr 88 15:05:00 -0500. <8804061603.AA15672@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
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 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
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".
You want to use the same name but have it mean something different? I'm
confused, sorry. Do you have an example?