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: 1108a1,c52c30d32b866eae X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public X-Google-Thread: fac41,c52c30d32b866eae X-Google-Attributes: gidfac41,public From: mbk@caffeine.engr.utk.edu (Matt Kennel) Subject: Re: Real OO Date: 1996/04/19 Message-ID: <4l92n3$1g6@gaia.ns.utk.edu>#1/1 X-Deja-AN: 150387396 references: followup-to: comp.lang.ada,comp.lang.eiffel,comp.object organization: University of Tennessee, Knoxville and Oak Ridge National Laboratory reply-to: kennel@msr.epm.ornl.gov newsgroups: comp.lang.ada,comp.lang.eiffel,comp.object Date: 1996-04-19T00:00:00+00:00 List-Id: Don Harrison (donh@syd.csa.com.au) wrote: : What I'm basically saying about Eiffel is that it's use would tend to maximise : reusability and flexibility in developed software due to the defaults of the : language: : a) reusability - the default is that a routine is extendable (not frozen) : b) flexibilty - the default is that entities are polymorphic, so will maximise : (theoretical) dynamic binding when used as actual parameters. : This equates to flexibility, IMO. : I acknowledge you can do exactly the same things in Ada but believe an Ada : programmer would typically use static binding more often than an Eiffel : programmer and would tend to use classwide operations more than an Eiffel : programmer. I'm an Eiffel fan but I'd disagree here. "polymorphism" is not like alms for the poor. Per se more 'polymorphism' doesn't mean 'better', it just means 'more polymorphism'. Personally I have lots of success with the Sather approach, where you can use concrete classes when you need to be specific about the type and abstract classes when you don't. These concrete classes are always available as sources for future implementation. You can get the same effect in Eiffel if the compiler has a common optimization. Never inherit from those classes which you want to use as a "final" concrete non-dispatching version. If you want to use their implementation in the future, then get it from a differently named superclass. If the compiler notices that a class has no descendants (and this fact can be discerned at at compile time) then it should not have to dispatch calls. So, if you see a class FOOBAR and you want to use it like it's concrete: make a new class MY_SPECIAL_CONCRETE_FOOBAR and inherit FOOBAR and don't do anything else. Very simple. The only difference in Sather is that you needn't make a separate concrete class from which you get implementation: a concrete class is both 'final' (not dispatchable) and remains a source of implementation for others. : Don. matt