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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC 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: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,b87849933931bc93 X-Google-Attributes: gidf43e6,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: kjhopps@mmm.com (Kevin J. Hopps) Subject: Re: What is wrong with OO ? Date: 1997/02/12 Message-ID: <3301D875.188B@mmm.com>#1/1 X-Deja-AN: 218262948 References: <5dopri$dei@news4.digex.net> Content-Type: text/plain; charset=us-ascii Organization: Imation Corp. Mime-Version: 1.0 Reply-To: kjhopps@mmm.com Newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object,comp.software-eng X-Mailer: Mozilla 3.01 (WinNT; I) Date: 1997-02-12T00:00:00+00:00 List-Id: Jon S Anthony wrote: > > In article <5dopri$dei@news4.digex.net> ell@access5.digex.net (Ell) writes: > > > Nick Leaton (nickle@calfp.co.uk) wrote: > > : richard@highrise.nl wrote: > > : > > > : > Virtual functions are also a kind of documentation. When declaring a > > : > function virtual, the programmer is more or less saying "go ahead, > > : > override this function if you like." > > : > > > > > : The decision to make a function virtual assumes a knowledge of what > > : users of your class are going to do. It akin to predicting the future. > > : One of the problems with C++ is this very point. Should you, as a > > : designer of a class restrict what someone else does with your class? > > > > How does making inherited classes able to override a parent function > > "restrict"ing "what someone else does with" that class"? > > This seems really confused. How are the _inherited_ classes > overriding a _parent's_ function? I suppose you meant subclasses. > Anyway, you got it backwards. The point is that if you don't make the > things virtual, you can't do the overrides (and other attendant > stuff). So, there is this problem of either making everything > virtual, and possibly providing misleading, inappropriate or possibly > simply inefficient aspects, or not and then risking the mentioned > problems. > > Nick is correct here. This is a problem in C++ (along with > friendship) as it requires prescience on the part of the developer > and/or various maintenance problems: if you later decide it should be > virtual, you have to go back and _change_ the source of the parent > thereby changing the semantics in various other places. If you decide > you need a new "friend" you have to go back and _change_ the source > (which you may not even have accesss to!) This problem is one which arises naturally in any OO design. For any class operation, the author of that class must make decisions about its semantics, and trust that subclasses adhere to those semantics. Regardless of the language used, there are times when the author may wish certain operations to remain fixed, while allowing others to be modified by a subclass. (Example folows.) If you later decide the semantics should be changed (i.e. the fixed operation should not be fixed), the semantics have changed. And changing semantics has a tendency to break things, even if you don't need to modify any code. For example, code may exist which depends upon the operation being fixed, and allowing a new class to alter the previously fixed behavior violates an assumption previously made. In languages that do not provide a choice between making functions overridable, documentation may be the only mechanism for making this distinction. C++ gives the author a way to state this explicitly so that the compiler can enforce it. This makes possible, in many cases, for the comiler to detect problems that occur when semantic changes are made. -- Kevin J. Hopps, Imation kjhopps@imation.com My opinions are my own. I speak neither for Imation nor 3M. Opinions expressed herein are my own and may not represent those of my employer.