Xref: utzoo comp.lang.eiffel:1332 comp.object:2428 Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!gatech!prism!hydra.gatech.edu!tynor From: tynor@hydra.gatech.edu (Steve Tynor) Newsgroups: comp.lang.eiffel,comp.object Subject: Re: Inheritance and Information Hiding Message-ID: Date: 25 Jan 91 16:06:11 GMT References: <1991Jan23.224203.3206@runx.oz.au> <1991Jan24.214652.18515@Think.COM> Sender: tynor@prism.gatech.EDU Followup-To: comp.lang.eiffel Organization: Georgia Tech Research Institute Lines: 27 In-reply-to: barmar@think.com's message of 24 Jan 91 21:46:52 GMT >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. In practice, I've found C++ `private's to be overly restrictive and in violation of the rule "it is not the buisiness for a class to decide how it may be extended in the future" (paraphrased from OOSC). It's another example of a C++ feature that actually reduces the reusability of C++ classes (non-virtual member functions being the other obvious one). =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= C++: Just say no. Steve Tynor Georgia Tech Research Institute Artificial Intelligence Branch tynor@prism.gatech.edu