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 (was Choice of OO primitives in Ada95) Date: 1996/03/15 Message-ID: #1/1 X-Deja-AN: 142923625 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-03-15T00:00:00+00:00 List-Id: Robert A Duff writes: :In article , :Don Harrison wrote: :>The only 'cost' is the effort of writing them in the first place but the benefit :>is enormous because that correctness is propagated through reuse. When assertions :>are used, there is nothing to fear from inheritance and no reason why all :>abstractions should not be candidates for reuse by inheritance. : :Well, assertions are a nice feature of Eiffel, but they don't :*guarantee* correctness. For example, there are some things that can't :be formalized, like "this procedure prints an error message that is :easily understood by any competent user". That's why Eiffel allows some :assertions to be merely comments, and of course if it's just a comment, :you can't know for sure that it's obeyed, unless you look at every :overriding. Granted. Not everything can be formalised. Of course, it's clearly valuable to exploit those aspects of a design that may be formalised. :>In contrast, assertion-less inheritance propagates errors through reuse. :> :>'Frozen' is used when the designer knows the implementation will not change. :> :>: Of course, the counter-argument is that you don't always know ahead of :>: time when you might need dispatching. :> :>Exactly. :> :>: I'm not sure I agree with Ray Toal, though, that requiring "tagged" is a :>: Good Thing. Even without that rule, Ada still gives you control over :>: whether things dispatch, on a call-by-call basis. So, I view "tagged" :>: as simply an efficiency hack. Efficiency is a Good Thing, too, though. :> :>Efficiency hack is a good way of describing it. : :Would you say "frozen" is (merely) an efficiency hack? I view it as :partly an efficiency hack, and partly an aid to understanding the :program. The two are different in a couple of ways: a) purpose - 'tagged' concerns dispatching whereas 'frozen' concerns redefinition b) syntactic necessity - 'tagged' is not necessary if the language allows dispatching by default. It is necessary, if dispatching is optional, as in Ada for the purpose of efficiency. [I happen to think dispatching by default would be better because the human benefits of flexibility and simplicity would outweigh the cost of bigger and better hardware]. - 'frozen' is necessary to indicate whether an operation may be redefined (which is not related to efficiency). :- Bob Don.