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: stt@henning.camb.inmet.com (Tucker Taft) Subject: Re: Real OO Date: 1996/04/04 Message-ID: #1/1 X-Deja-AN: 145830271 sender: news@inmet.camb.inmet.com (USENET news) x-nntp-posting-host: henning.camb.inmet.com references: followup-to: comp.lang.ada,comp.lang.eiffel,comp.object organization: Intermetrics, Inc. newsgroups: comp.lang.ada,comp.lang.eiffel,comp.object Date: 1996-04-04T00:00:00+00:00 List-Id: One correction, and one comment... Don Harrison (donh@syd.csa.com.au) wrote: : In case anyone is confused about how Eiffel's and Ada's parameter mechanisms : compare, the following hopefully summarizes them: : SUPPLIER CLIENT BINDING : -------- ------ ------- : Assuming: : Ada: : type A_TYPE is private -- tagged m: A_TYPE; : type B_TYPE is private -- tagged mc: A_TYPE'Class; : n: B_TYPE; : nc: B_TYPE'Class; : Eiffel: : class A_TYPE ... end m: A_TYPE : class B_TYPE ... end n: B_TYPE : Case1 : ----- : Ada: : procedure f (a: A_TYPE) f (m); static : f (mc); dynamic : But if f not defined in same spec: : f (m); static : f (mc); static f(mc) is not legal in Ada. You can't pass a dynamically tagged operand like "mc" to something that expects a specific type like A_TYPE. This rules helps to avoid confusion about what is and what is not dynamically bound, and to avoid implicit "truncation" or "slicing" as it is sometimes called. Unintended "slicing" is a relatively common source of bugs in C++. : Eiffel (inside A_TYPE): : f m.f dynamic : ... : Conclusion: : Ada: : - more efficient, but : - manual optimisation places a burden on developer This really isn't optimization, in my view. It is simply distinguishing between a specific type and a set of types. I doubt if the programmer is even thinking in terms of optimization. I presume they are more thinking in terms of correctness and maintainability. : - reduced flexibility/reusability I don't agree with this. When dynamic binding is used willy-nilly and without explicit intention, you don't get flexibility, you get a maintenance nightmare. You can exactly match the Eiffel "flexibility" by using dynamic binding explicitly, so the only difference is whether the default is dynamic or static binding. This has more to do with readability and intent, than with more or less flexibility. The rule for what is dynamically bound in Ada is basically just this: You get dynamic binding only when passing a class-wide controlling operand to a dispatching operation. Everything else is statically bound. : ... : Don. -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Cambridge, MA USA