Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!rochester!hood.cc.rochester.edu!news.acsu.buffalo.edu!dsinc!spool.mu.edu!munnari.OZ.AU!news.ecn.uoknor.edu!feed1.news.erols.com!howland.erols.net!blackbush.xlink.net!unlisys!cs.tu-berlin.de!news.uni-hamburg.de!news.Hanse.DE!wavehh.hanse.de!cracauer
From: cracauer@wavehh.hanse.de (Martin Cracauer)
Subject: Re: CLOS and information hiding
Message-ID: <1997Mar3.091715.12836@wavehh.hanse.de>
Reply-To: cracauer@wavehh.hanse.de
Organization: '(a (cons tructive organization))
References: <01bc13dc$cfaa2b20$0f02000a@gjchome.nis.newscorp.com> 	<330512CF.6458@acm.org> <330664CD.2AEA@cc.umanitoba.ca> 	<330b4d8a.7824414@news.wam.umd.edu> 	<5etf3a$bjs$1@goanna.cs.rmit.edu.au> 	<33151E7D.58C3@research.nokia.com> <3066031941459593@naggum.no> 	<gmpvxmeacq.fsf_-_@pelle.som.fi> <3066034061855177_-_@naggum.no> <gmn2sqe7gk.fsf@pelle.som.fi>
Date: Mon, 3 Mar 97 09:17:15 GMT
Lines: 59

Ola.Rinta-Koski@iki.fi (Ola Rinta-Koski) writes:

>In article <3066034061855177_-_@naggum.no> Erik Naggum <erik@naggum.no> writes:
>> * Ola Rinta-Koski
>> | I used to program in Common Lisp, and hence CLOS.  One thing which
>> | bothered me was the apparent lack of information hiding in using classes
>> | and methods.
>> 
>> why do you want information hiding in the first place?

[I took the freedom to change the sequence of your paragraphs]

>  I suppose there is a good reason why CLOS does not have information
>hiding (or if it has, does things differently from, say, C++). I just
>never came across that reason.

One reason for "public" slots in CLOS, besides the others pointed out
by other posters are probably multimethods. When defining
multimethods, it is not that obvious which slots you want to access
from which object or class. You need to specify them to use them in
multimethods. A mechanism to determine which slots you are allowed to
use and which not on the base of the classes you specialize you
methods on is imaginable. But people obviously thought it is not worth
the effort, a complication of the language and the implementation.

>  I find it convenient to be able to see from the declaration which
>methods and slots are to be available to other classes and which are
>internal to the class, and even more importantly that I won't
>accidentally (or that someone using my class won't be tempted to) use
>internal parts where I shouldn't. In my opinion the environment should
>help me attain that goal.

In Common Lisp, you get information hiding only at a package level. In
practice, this means first of all that you can't hide details of one
class to other classes in the same package, but you can hide details
from users of this package. In my opinion, that serves the goal
sufficiently.

Of course, information-hiding at a finer-graded level is useful for
many people's thinking. But CLOS is a dynamically typed language and I
think before you ask for more security information-hiding wise, you
would need a statically typed language first. The number of errors you
avoid by C++ information hiding, but not by Lisp package hinding is
probably neglectable to the number of type errors.

Maybe my view is too narrow, but when I want detailed
information-hiding to avoid unintended use of my libraries, I probably
want static type checking, too. Of course, I mix two different issues
here (ensuring "right" usage of code versus programming style), but in
practice I thing these two are quite related, because both are on the
same side of "secure/comlex-vs-flexible/simple" programming language
design.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin_Cracauer@wavehh.hanse.de http://cracauer.cons.org  Fax.: +4940 5228536
"As far as I'm concerned,  if something is so complicated that you can't ex-
 plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
