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: jhd@herold.franken.de (Joachim Durchholz) Subject: Re: Real OO Date: 1996/03/23 Message-ID: <65O34ib-3RB@herold.franken.de>#1/1 X-Deja-AN: 144206422 distribution: world references: <4id031$cf9@dayuc.dayton.saic.com> newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object Date: 1996-03-23T00:00:00+00:00 List-Id: ncohen@watson.ibm.com wrote 22.03.96 on Re: Real OO: > ...a specific type as an Eiffel reference whose dynamic type is known to be > identical to its static type. A method call can be far more efficient if > this knowledge is conveyed to the compiler, and it is common in practice > for this knowledge to be available. The Eiffel paradigma is that it should *not* be possible to fix a formal parameter's dynamic type to its static types. Such a thing is considered an unnecessary limitation introduced on the routine, for efficiency reasons that aren't even valid because a compiler can determine wether such an optimization is possible. In fact, all Eiffel literature on the subject strongly encourages compiler writers to replace dynamic cally by static calls whenever possible, and to inline code wherever it makes sense. > For a one-parameter subprogram, the effect of a classwide subprogram > could be achieved by a dispatching subprogram that is never overridden. Agreed. > Making it classwide simply documents the fact that the algorithm does not > depend on the tag of the parameter, and causes the compiler to catch any > attempt to override. This assumes that the writer of a module knows that his routines never need to be overridden. While this may be true when writing a program with a fixed and well-understood task, this isn't true when writing libraries, or when programs are modified in the future and in ways that weren't anticipated. 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. > The real power of a classwide program arises with > multiple parameters. In Eiffel, dispatching is controlled by the one > object whose method is invoked (the x in x.f()). In an Ada dispatching > subprogram, there can be multiple parameters controlling the dispatching. > > [Omitting details on dispatching based on the dynamic type of 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. I'm not sure wether this is enough to handle all cases that arise in practice, but it goes a long way. BTW I see serious problems with the Congruent function given. Consider descandant types "Filled_Circle", "Hatched_Circle" etc. - with the understanding that these don't have any new geometric properties that should influence Corresponding_Parts_Equal or Congruent. First of all, it would be necessary to define a Corresponding_Parts_Equal function for each pair of Circle_Type descendants - this can become quite a formidable task if the number of direct and indirect descandants grows. In addition, the Congruent code will break - Shape1'Tag and Shape2'Tag will not be equal, making Congruent return false even if a Filled_Circle and a Hatched_Circle actually have equal corresponding parts. -Joachim -- Im speaking for myself here. ## CrossPoint v3.1 ##