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: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,c52c30d32b866eae X-Google-Attributes: gid1108a1,public From: donh@syd.csa.com.au (Don Harrison) Subject: Re: Real OO Date: 1996/04/12 Message-ID: #1/1 X-Deja-AN: 147055238 sender: news@assip.csasyd.oz references: <4kbqun$iiv@watnews1.watson.ibm.com> organization: CSC Australia reply-to: donh@syd.csa.com.au newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object Date: 1996-04-12T00:00:00+00:00 List-Id: Norman H. Cohen writes: :In article , donh@syd.csa.com.au (Don :Harrison) writes: [...] :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. I must confess to still being in the woods over whether: corresponding_parts_equal (other: like Current): BOOLEAN is ... means that, in a call x.corresponding_parts_equal (y): a) the STATIC type of y must conform to the STATIC type of x, or b) the DYNAMIC type of y must conform to the DYNAMIC type of x ('conform to' meaning having the same (or more specific) type). ETL seems to suggest a): [22.9 - The call validity rule]. This says: "... if x is anchored to another final argument, as in r (z:T; x: like z) is ... then y of type YT conforms to x in a call r(u,y) if u is of type UT (conforming to T) and YT conforms to UT.". I assume this is talking about static conformance. Also, [13.8 - Expression conformance] gives the example: "x: CT; y: DT; ... if equal (x,y) then ...". I haven't been able to find anything about dynamic conformance. As you imply, a call in which the STATIC types of the actual parameters conform but the DYNAMIC types do not is a possible source of difficulty. How about swapping the order of parameters: frozen corresponding_parts_equal (other: like Current): BOOLEAN is do if not other.conforms_to (Current) then -- inherited from ANY Result := other.parts_equal (Current) -- dispatch else Result := parts_equal (other) -- dispatch end end parts_equal (other: like Current): BOOLEAN is do ... end Would you use a classwide operation in Ada to do the same trick? ... and get around the following problem?: :|> ... 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) ). Note that the symmetry of multiple controlling operands may exist statically but may be non-existent dynamically. To acheive something that works in this situation, you have to redefine the operation as classwide anyway. Such symmetry that only exists in the special case of all actual parameters having the same dynamic type is of questionable value, IMO. :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? Assuming you mean 'where the dynamic type of A conforms to the dynamic type of B' (rather than the reverse): :Some possible answers: : :(a) It is impossible to write a routine that has such expectations. : [If so, Eiffel is less flexible than Ada.] No. :(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!] I wish! :(c) A run-time error results immediately. : [If so, no different from Ada.] Don't think so. :(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.] Not quite. As shown above, a correctly designed algorithm will give the correct result in all circumstances. :Please enlighten us. I hope someone will enlighten me about whether my interpretation of ETL is correct. :-- :Norman H. Cohen ncohen@watson.ibm.com Don.