From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: Alan Lovejoy Subject: Re: OO, C++, and something much better! Date: 1997/01/30 Message-ID: <32F07705.289C@concentric.net>#1/1 X-Deja-AN: 213196012 references: <32DF458F.4D5C@concentric.net> <32DF94DC.6FF8@watson.ibm.com> <32DFD972.37E4@concentric.net> <5bphq4$5js@mulga.cs.mu.OZ.AU> <32E05FAF.47BA@concentric.net> <5buodl$bci@boursy.news.erols.com> <32E2FEC7.2F7B@concentric.net> <5bvncj$gqg$1@A-abe.resnet.ucsb.edu> <32E47B4B.56D9@concentric.net> <32E4E6E1.437E@dstsystems.com> <32EE858E.FAD@concentric.net> <5cobea$cm8@news1.ucsd.edu> content-type: text/plain; charset=us-ascii organization: Modulation mime-version: 1.0 newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object x-mailer: Mozilla 2.01Gold (Win95; U) Date: 1997-01-30T00:00:00+00:00 List-Id: Matt Kennel wrote: > > Alan Lovejoy (alovejoy@concentric.net) wrote: > > : And a strong case can be made that having the compiler check based on "types" > : (actually type constraints/assertions) assigned to variables (not objects) > : is a severe violation of the information hiding principle. An object should > : ideally be a black box that hides its implementation (class). Exposing the > : interface of the object is acceptable, even good. But most statically-typed > : OO languages go beyond that into exposing the implementation (class)--and then > : hard coding it into type constraints on variables in the program source, which > : is very, very bad. > > 1) Why is this very very bad? Why is it non-very bad? Because it fails to separate interface from implementation. > 2) The type constraints on variables do not necessarily prescribe any > particular concrete class, much less expose any internal class information > to extra manipulation. What is the relation to "information hiding"? The > inside-vs-outside encapsulation generated by Eiffel classes or Ada packages > or M3 modules has no relation to type constraints on variables, as far > as I can see. I thought I made it clear that I was specifically deprecating those languages that use **classes** as type constraints. And I thought I made it clear that "Exposing the interface of the object is acceptable, even good." And I agree that the way static typing is done in Ada, Modula-3 and Eiffel is quite superior to what C++ does. But I would be even happier with the way Ada or Eiffel handle typing if one could simultaneously have two different variables whose static type constraint is "Dictionary" but where each is actually an instance of a different class (say HashTable and BinaryTree)--and the only class they both have in common in their inheritance hierarchy is Object. > : Using the class as a substitute for the interface violates the information hiding > : principle. This was and is the issue. > > 3) And suppose you actually want to specify a particular concrete class? > You have [to] "hard code" classes to create instances, after all. VAR dictionary1, dictionary2: Dictionary; BEGIN dictionary1 := new HashTable; dictionary2 := new BinaryTree; Does that answer your questions? -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================|