From ...
From: Erik Naggum <erik@naggum.no>
Subject: Re: CLOS and information hiding
Date: 1997/02/27
Message-ID: <3066042341749112@naggum.no>#1/1
X-Deja-AN: 221822466
References: <gmpvxmeacq.fsf_-_@pelle.som.fi> <3066034061855177_-_@naggum.no> <gmn2sqe7gk.fsf@pelle.som.fi>
mail-copies-to: never
Organization: Naggum Software; +47 2295 0313; http://www.naggum.no
Newsgroups: comp.lang.lisp


* Ola Rinta-Koski
| 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.

the package system should be able to separate the externally visible from
the internal methods and the accessor functions publish the accessability
for slots, don't they?  a class in CLOS doesn't contain its methods, so the
class cannot hide them, either.  in effect, a class in C++ is like a
package as far as the accessibility of symbols are concerned.

| 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.

the purported reasons for having "information hiding" in the first place
have actually eluded me all these years.  the "friend" concept in C++ tells
me that its information hiding is at a much too fine granularity, too.

I don't know what the right level of information hiding would be, but I
"grew up" with Simula (at the U of Oslo), and I still think information
hiding is the least useful aspect of object-oriented programming.  I think
"black box" pertains to the user of a system, not that it is an intrinsic
quality of the system itself.

actually, the more I think about this information hiding stuff, the more I
get the feeling that it's most suitable to ex-post-facto-programming: after
you have done all your design work, learned all there is to learn about the
problem domain, you or somebody else sits down to code it all to a defined
specification.  this is not a useful model for me, since I learn about the
problem while I solve it and frequently revise my opinion on the design and
the implementation.  (I think the same is true for _any_ creative work, and
it's much more important to me to be able to explore and learn than just to
code a solution.  it could be that C++ is not creative work -- that the
creative part should precede coding -- but I don't think that is a good
approach to programming, at least not for me.)

I have never felt the need for information hiding, and it's always been in
my way, but I'd like to hear of cases where it has been invaluable.  I'm
sure this stuff isn't _all_ drummed up by marketing boys.  :)

#\Erik
-- 
if you think big enough, you never have to do it