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/04 Message-ID: #1/1 X-Deja-AN: 145737375 sender: news@assip.csasyd.oz references: <4j9p3a$uo5@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-04T00:00:00+00:00 List-Id: Norman H. Cohen wrote: :In article <65O34ib-3RB@herold.franken.de>, jhd@herold.franken.de :(Joachim Durchholz) writes: [...] :No routine, even in an object-oriented program, is immune from future :modification resulting from new requirements that change the routine's :preconditions and postconditions. However, a classwide routine will :generally not have to be modified just because a new type was added to :the class hierarchy. No routine of any kind - frozen (classwide) or redefinable - needs to be modified because descendants are declared; it is only necessary if the design of the parent changes. : A classwide routine is, by definition, one whose :correctness does not depend on the dynamic types of the objects it is :dealing with. Apart from the efficiency aspect, I wonder is the eagerness of Ada programmers to freeze routines related to the fact that assertions aren't available to: - guard against errors in parents being propagated into descendant classes, and - correctness in parents being compromised in descendants? ;-) :|> Considering the fact that fixed and well-understood tasks don't need OO :|> (structured programming and functional decomposition should suffice for :|> this type of tasks), this argument gains some weight. : :That's a rather limited view of the utility of OO techniques! Even fixed :and well understood tasks benefit from data abstraction and :encapsulation, from the use of inheritance to avoid redundant effort, and :from the use of polymorphism to facilitate generalized algorithms. : :Like any other program, an OO program reflects a model of the problem :domain and the ways in which it is likely to evolve. If the problem :domain evolves in the ways that the original designers anticipated, the :program can be updated to reflect this evolution simply by the addition :of new subclasses. But if the problem domain evolves in ways :inconsistent with the original designer's model, no OO technique is going :to save your code from major surgery. With such an appreciation of OO, you ought to be a big fan of Eiffel! :Concerning dispatching based on multiple parameters: : :|> The type of dispatching noted here can easily be achieved with anchored :|> types in Eiffel. In an Ada-style notation, this would look as follows: :|> :|> function Corresponding_Parts_Equal :|> (Self: Shape_Type; Other: like Self) :|> return Boolean :|> :|> The "like Self" part requires Other to have the same dynamic type as Self, :|> or a type that is a descendant of Self's type. : :(Are you sure it's the DYNAMIC type? Section 11.4.3 of Meyer's :_Object_Oriented_Software_Construction_ seems to suggest that it's the :declared type.) No. It's the static type. Further, if you say 'like Current', it is the static type of the class in which the routine is defined. The purpose of anchored types is to define type dependence and to do it once only. The dependence is propagated into descendants automatically. Otherwise, you would have to redefine such dependence even if implementations were otherwise identical (not that they would be in this example): - in class SHAPE_TYPE: corresponding_parts_equal (other: SHAPE_TYPE): BOOLEAN is do ... end - in class RECTANGLE_TYPE: corresponding_parts_equal (other: RECTANGLE_TYPE): BOOLEAN is do ... end BTW, I notice Ada people have a penchant for humungous identifiers. Is this an unconscious attempt to balance out the heavy syntax? ;-) :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) ). [discussion about lack of symmetry omitted because it is erroneously assumes runtime conformance to dynamic rather than static types] :-- :Norman H. Cohen ncohen@watson.ibm.com