Newsgroups: comp.lang.clos
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!lucid.com!jonl%kuwait
From: jonl%kuwait@lucid.com (Jon L White)
Subject: CLOS Private Methods
Message-ID: <9106271914.AA14030@kuwait>
Sender: daemon@cis.ohio-state.edu
Organization: The Ohio State University Department of Computer and Information Science
References: <1991Jun26.202149.1346@ircam.fr>
Date: Thu, 27 Jun 1991 19:14:25 GMT
Lines: 32

re: An "Object Oriented system without any information hiding" !?

That's a gross overstatement (despite Harley's acquiescence for the
sake of argument.)

It may be belaboring the point, but it needs to be said again:

   In a world with the kind of dynamism of Common Lisp, "information
   hiding" and "Encapsulation" have to mean different things.

For example, "information hiding" in the context of the "other"
object systems often means nothing more than lexical scoping.  You
are aware of the lexical constructs in Common Lisp, no?

But suppose for example that a language like C embodied the notion
of first-class symbol-tables available at runtime -- with perhaps
an access protocol such as you might use in typical C debuggers.
What would "information hiding" mean then?  Everything is inherently
accessible, albeit by a few lines of symbol-table programming rather
than a purely static token.

With the dynamism of Lisp, a notion of module-spearated names is
not a bad idea.  Common Lisp packages is one cut at this approach;
it leaves as much as possible still inherently accessible, but with
some suggested "safe" protocols.  Some other kindred approaches would 
cut out a lot of the runtime accessibilies -- in pretty much the same 
way that most Common Lisp compilers cut out the actual symbol on 
compiled, lexically-local variables.  But for a language with a full 
reflective power, you need that accessibility.


-- JonL --