Xref: utzoo comp.lang.eiffel:1330 comp.object:2426
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.lang.eiffel,comp.object
Subject: Re: Inheritance and Information Hiding
Keywords: oop, ood, Eiffel, inheritance, information hiding
Message-ID: <1991Jan24.214652.18515@Think.COM>
Date: 24 Jan 91 21:46:52 GMT
References: <1991Jan23.224203.3206@runx.oz.au>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 29

In article <1991Jan23.224203.3206@runx.oz.au> chrisv@runx.oz.au (Chris Velevitch) writes:
>I disagree with allowing a class to access inherited features that are
>not exported. It does not make sense that secret features are known to
>heir of a class. If a feature is not publicly known, then how can you
>know about the feature to use in the descendent class.

I like C++'s solution to this, the private/protected/public distinction.
The private members of a class are only visible within the class, internal
to the "black box".  Protected members are visible to derived classes;
frequently class derivation is used to extend behavior, in which case it is
reasonable to allow a more intimate relationship between the base class and
the subclasses, and protected members can be used for this.  And public
members are fully exported.

The applicability of information hiding ideas can depend heavily on the
design of the OO language.  For instance, it's hard to provide this could
be done in CLOS, because there is no notion of methods "belonging" to a
particular class, due to its support of generic function dispatch based on
the types of multiple arguments.  I suppose there could be rules specifying
that WITH-SLOTS and WITH-ACCESSORS may only be used on specialized
parameters, and may only specify slots visible within the class named in
the parameter specializer.  This would support information hiding with
regard to data, but it's not clear how to extend it to procedures.

--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar