From ... From: Erik Naggum Subject: Re: CLOS and information hiding Date: 1997/02/27 Message-ID: <3066042341749112@naggum.no>#1/1 X-Deja-AN: 221822466 References: <3066034061855177_-_@naggum.no> 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