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,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: jsa@organon.com (Jon S Anthony) Subject: Re: Real OO Date: 1996/04/04 Message-ID: #1/1 X-Deja-AN: 145816718 sender: news@organon.com (news) references: <4jbmsk$uo5@watnews1.watson.ibm.com> organization: Organon Motives, Inc. newsgroups: comp.lang.ada,comp.lang.eiffel,comp.object Date: 1996-04-04T00:00:00+00:00 List-Id: In article donh@syd.csa.com.au (Don Harrison) writes: > In case anyone is confused about how Eiffel's and Ada's parameter mechanisms > compare, the following hopefully summarizes them: [reasonably synopsis of binding time stuff for Ada and Eiffel, though misleading in the case of class wide types for the uninitiated] But, > Conclusion: > > Ada: > - more efficient, but > - manual optimisation places a burden on developer > - reduced flexibility/reusability > - syntactically complex > > Eiffel: > - less efficient, but > - automatic optimisation means that the the efficiency gap is reduced as is > the burden on developer > - greater flexibility/reusability > - syntactically simple I'm not clear on why you keep saying this - well, aside from evangelizing that is. I'm not clear on why you think that localizing polymorphism is somehow "manual optimization"? Sure the Ada compiler can do similar analysis as an Eiffel compiler if everything is always a polymorphic call, and you can do this if you want and be equivalent to Eiffel, so this seems irrelevant. That is, the Eiffel case is a subclass of what you can do in Ada. I think the localization of polymorphism revolves around clarity of code and maintenance issues. That's certainly what I like about it and why I think it clearer than the Eiffel/Et.Al. approach. [Aside: Note that Sather is _more_ like Ada in this respect than Eiffle. I guess this is one reason why I think Sather is a _significant_ improvement over Eiffel. Hey, there adding modules too! And it has those way cool iterators and... Now, if only there were some industrial strength implmentations, I might be tempted...] Second, what's less flexible or "reusable"? I know you keep saying this but nothing you've said has any convincing content - or maybe I've missed something. Maybe you think that because a class wide operation is static binding it somehow prevents polymorphic values/processing?? That is not true. For example, > procedure i (a: A_TYPE'Class; b: B_TYPE'Class) i (m, n) static > i (m, nc) static > i (mc, n) static > i (mc, nc) static Note that i can be passed _anything_ in the type trees rooted at A_Type and B_Type (including A_Type'Class and B_Type'Class). How is the Eiffel more flexible/reusable?? In fact, it would seem that this approach is _more_ flexible and _robust_ to changes (more like Sather abstract types) Lastly, I don't understand why you think that the function style is more "syntactically complex". I suppose you just have a preference and describe this as an objective fact, but that is not particularly convincing. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com