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: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: kennel@lyapunov.ucsd.edu (Matt Kennel) Subject: Re: OO, C++, and something much better! Date: 1997/01/29 Message-ID: <5cobea$cm8@news1.ucsd.edu>#1/1 X-Deja-AN: 213082101 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> followup-to: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object organization: The University of California at San Diego newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object Date: 1997-01-29T00:00:00+00:00 List-Id: 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? 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. : 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 "hard code" classes to create instances, after all. : -- : Alan L. Lovejoy |==============================================| : Smalltalk Consultant | Beware of Geeks bearing GIFs! | : alovejoy@concentric.net |==============================================|