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: fac41,c52c30d32b866eae X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,c52c30d32b866eae X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public From: ncohen@watson.ibm.com (Norman H. Cohen) Subject: Re: Real OO Date: 1996/04/08 Message-ID: <4kbqun$iiv@watnews1.watson.ibm.com>#1/1 X-Deja-AN: 146410175 distribution: world references: <4j9p3a$uo5@watnews1.watson.ibm.com> organization: IBM T.J. Watson Research Center reply-to: ncohen@watson.ibm.com newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object Date: 1996-04-08T00:00:00+00:00 List-Id: In article , donh@syd.csa.com.au (Don Harrison) writes: |> With such an appreciation of OO, you ought to be a big fan of Eiffel! I have nothing against Eiffel, and my background in formal methods makes me especially appreciative of the Eiffel approach to formalizing inheritance, but I find the Ada model of dispatching less error-prone and more flexible. Your remark betrays a provincial view, however--that Eiffel is the One True Answer for all those who want to write OO programs. Smart-aleck one-liners like |> BTW, I notice Ada people have a penchant for humungous identifiers. Is this |> an unconscious attempt to balance out the heavy syntax? ;-) only confirm this. You ought to open your mind and broaden your horizons. Let's try to return the discussion to technical arguments. |> :It's the "or a type that is a descendant of" that differentiates the |> :Eiffel approach from the Ada approach. |> |> ... and makes the Eiffel approach more flexible (and robust: Ada raises a |> Constraint_Error exception if the dynamic types of multiple controlling |> operands differ RM95 3.9.2 (16) ). What does Eiffel do in the case of a call like A.Corresponding_Parts_Equal(B) where A and B have different dynamic types, but the version of Corresponding_Parts_Equal for the dynamic type of A expects the parameter to be of (or descendended from) the dynamic type of Current? Some possible answers: (a) It is impossible to write a routine that has such expectations. [If so, Eiffel is less flexible than Ada.] (b) The Eiffel translator magically deduces an algorithm for Corresponding_Parts_Equal that works for the two dynamic types in question. [If so, we can stop this discussion now, I'm sold on Eiffel!] (c) A run-time error results immediately. [If so, no different from Ada.] (d) The version of Corresponding_Parts_Equal for the dynamic type of A is invoked with a parameter that does not have the expected dynamic type. Depending on the algorithm for that version of the routine, this may lead indirectly to a run-time error later, or fortuitously happen to give the right answer (at least for all the cases we tested so far ;-) ), or give an incorrect answer masquerading as a correct answer. [In any of these cases, Ada is more robust.] Please enlighten us. -- Norman H. Cohen ncohen@watson.ibm.com