Re: CLOS, and slot hiding.

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

    Date: 6 Apr 88 10:40 PDT
    From: Danny Bobrow <Bobrow.pa@Xerox.COM>
    
>I agree with the comments made by Moon about the design goals of
>CLOS.  Alan Snyder made a big pitch for having encapsulation be an
>important goal for the Common Lisp community, and it was rejected.
>One reason is that it was hard (as Moon mentioned) and another is
>because it does not fit into the philosophy of Lisp, which has always
>prided itself on being an open system (this is the point that Jim
>made so well).

Frankly, I think we should eliminate lexical scoping then and all go
back to using global special vars and functions everywhere.  After
all, we want an "open" system. Now seriously. Abstraction features
that are useful and allow programmers to easily practice useful
information hiding are in no way opposed to "open" systems. The two
concepts are utterly orthogonal. I don't want to prevent people who
want to know how my classes are implemented from finding out.  I just
dont want them to HAVE to find out in order to use my class as a
superclass. I especially don't want them to find out the hard way, by
having their methods interact with superclass methods in an obscure
manner. 

So much for the "open" philosophy issue. As for it being "hard" to implement,
this may be a legitimate objection; however, lots of things in 
CLOS are "hard" to implement in both the sense of semantically difficult
to achieve correctness, and in terms of required run-time inefficiency.
Is there some horrible interaction that a class-specific slot option 
would have with other aspects of CLOS semantics which I am overlooking?
My intuition is that a change to with-slots would provide the necessary
semantics, and that it could be implemented via the SYMBOL-MACROLET
facility and some gensymming.


...mike beckerle