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,f66d11aeda114c52 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,f66d11aeda114c52 X-Google-Attributes: gid103376,public From: Joachim Durchholz Subject: Re: Design By Contract Date: 1997/09/06 Message-ID: <34108452.BAF03BA5@munich.netsurf.de>#1/1 X-Deja-AN: 270073398 References: <872172435.980@dejanews.com> <3403940F.4154@pseserv3.fw.hac.com> <3403C44F.2424@erols.com> <5u3c6v$gtf$2@miranda.gmrc.gecm.com> X-Priority: 3 (Normal) Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 1997-09-06T00:00:00+00:00 List-Id: Patrick Doyle wrote: > >Dynamic binding and "frozen" are orthogonal issues. > > Now, have a look at the quote you took, and tell me how it > contradicts this. Nonvirtual C++ functions and frozen Eiffel routines are not the same. 1) Even a frozen routine can be polymorphic - it may itself override an inherited routine. (This is not an issue for the frozen features declared in ANY, PLATFORM or GENERAL.) 2) There is no way in Eiffel to achieve the effect of C++ nonvirtual member functions. If you have a routine blah (x: A_CLASS) is do x.do_something end the standard C++ policy (nonvirtual routine) would be to always call A_CLASS.do_something, regardless of wether the parameter passed in for x is of that type or of a descendant. In Eiffel, the decision which routine to call will always be based on the run-time type of x, *never* on the declared type along. (Of course, if do_something is frozen in A_CLASS, no polymorphism is possible, so the compiler should optimize this to a static call. But that's the same as when the compiler determines that only A_CLASS objects will be passed for x in the given program.) Regards, Joachim -- Please don't send unsolicited ads.