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,c52c30d32b866eae X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,c52c30d32b866eae X-Google-Attributes: gid1108a1,public From: donh@syd.csa.com.au (Don Harrison) Subject: Re: Real OO Date: 1996/04/12 Message-ID: #1/1 X-Deja-AN: 147090340 sender: news@assip.csasyd.oz references: organization: CSC Australia reply-to: donh@syd.csa.com.au newsgroups: comp.lang.ada,comp.lang.eiffel,comp.object Date: 1996-04-12T00:00:00+00:00 List-Id: Tucker Taft) writes: :One correction, and one comment... : :Don Harrison (donh@syd.csa.com.au) wrote: [...] :: Conclusion: : :: Ada: :: - more efficient, but :: - manual optimisation places a burden on developer : :This really isn't optimization, in my view. It is simply :distinguishing between a specific type and a set of types. Yes, it may be that an Ada programmer might choose static binding because they know the entity happens to be of a specific type. This is fine if it is known that the type is absolutely set in concrete. However, we need to consider why it is known. Normally, it will be known because the (transitive) source of the value it last received was itself a statically bound call. That is, one designed to handle a specific abstraction, rather than a family of abstractions; it is not designed for reuse. If the routine servicing the call is designed for reuse, then it returns an indeterminate dynamic type which demands dynamic binding when we use the returned entity as an actual parameter to the operation we are designing. Generally speaking, if there are many opportunities of using entities of specific types, it is indicative of a low level of reuse. I think most would agree that well written software maximises reuse. If the above analysis is valid, it also maximises dynamic binding. :I doubt if the programmer is even thinking in terms of :optimization. I presume they are more thinking in terms :of correctness and maintainability. Don't agree. If reuse, and hence, dynamic binding is maximised (in a safe way: supported by assertions), then so is correctness and maintainability. :: - reduced flexibility/reusability : :I don't agree with this. When dynamic binding is used willy-nilly :and without explicit intention, you don't get flexibility, you get :a maintenance nightmare. No. If you have high reuse with assertions, you have a maintenance dream! : You can exactly match the Eiffel "flexibility" :by using dynamic binding explicitly, so the only difference is whether :the default is dynamic or static binding. This has more to do with :readability and intent, than with more or less flexibility. Yes. The philosophy in Eiffel of maximising reuse means that dynamic binding is chosen as the correct default, IMO. [...] : :-Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ :Intermetrics, Inc. Cambridge, MA USA Don.