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: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public From: doylep@ecf.toronto.edu (Patrick Doyle) Subject: Re: Interface/Implementation (was Re: Design by Contract) Date: 1997/09/05 Message-ID: #1/1 X-Deja-AN: 270005357 X-Nntp-Posting-Host: skule.ecf Sender: news@ecf.toronto.edu (News Administrator) References: <340F20A0.49B5@ac3i.dseg.ti.com> Organization: University of Toronto, Engineering Computing Facility Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-05T00:00:00+00:00 List-Id: In article <340F20A0.49B5@ac3i.dseg.ti.com>, John G. Volan wrote: > >Well, one problem with using abstract/deferred classes as a simulation >for separate interfaces, is that the former might do _too much_. You >wind up getting polymorphic dynamic dispatching in situations that don't >really call for it. This can result in an unnecessary run-time >performance penalty when a given program includes only one concerete >implementation class for a given abstract class (unless your programming >environment is able to detect and optimize this situation). The only time when dynamic dispatching can be avoided is when the call is not polymorphic. If it is polymorphic, then the compiler can still optimize it anyway, so we haven't lost anything in this department. >In Ada, every single package must have a separate spec, so Ada >programmers are used to applying this pattern everywhere. But is it really necessary everywhere? Or just where interfaces need to be frozen? >But I'd wager >that very few Eiffel programmers would consider introducing an abstract >parent class for every one of their concrete classes, just to simulate >Ada packaging. I'd assume that abstract/deferred classes appear in >typical Eiffel programs just as frequently as abstract tagged types do >in Ada95 programs, and that they typically serve the same role: >implementing generalization/specialization hierarchies. I'd tend to agree. Using abstract parent classes in this manner is a very important usage. Using them to freeze an interface is another important usage. >So I don't see abstract classes as a very good mapping for Ada package >specs, and I agree with those who compare Ada specs to Eiffel short >forms. I've argued before that an Eiffel short form is just an abstract parent class generated after the fact. So if Ada specs compare with Eiffel short forms, then they compare with abstract parent classes. -PD -- -- Patrick Doyle doylep@ecf.utoronto.ca