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,953e1a6689d791f6 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,953e1a6689d791f6 X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: To overload or not to overload (was Eiffel and Java + Ada dispatching) Date: 1996/11/14 Message-ID: #1/1 X-Deja-AN: 196345643 sender: news@organon.com (news) references: organization: Organon Motives, Inc. newsgroups: comp.lang.eiffel,comp.lang.ada Date: 1996-11-14T00:00:00+00:00 List-Id: In article donh@syd.csa.com.au (Don Harrison) writes: > Now the contentious part. :( The issue of which model is 'correct' > depends on which operation of B can better be regarded as > functionally equivalent to the operation in A. (The safety issue is > secondary, IMO - I'm talking about modelling integrity). What seems > to happen in the real world is that as The real world has nothing to do with it. What is "modelling integrity" anyway? > interactions between things become more specific, the things > involved become more specific as well (or some may stay the > same). (The things do not become *less* specific, but that is > another matter). To model this faithfully, Things in the world aren't specific or general at all. That is an artificial organizational constraint applied in the semantics of some modeling schemes (taxonomic...) You really must separate the world from the formalism or you will never get anywhere. > :but then you have to rename). Thus, in a piece of code where an operation > :is applied to arguments suitable only for the inherited version, Eiffel > :will signal a type error (system validity or by runtime crash :-), > > IMO, this is what ought to happen because because the operation has become > more specific and so requires more specific parameters. Well, in a covariant model. But why think that is all there is or even that it is the best???? There's just no evidence for it. > must be fixed. If a more general operation realy *is* required, then > you can define a *new* operation [(6) in my example] for this > purpose. So, Eiffel dispatches to a more specific operation by > default rather than to a more general one. This differs from Ada > which ... > > : will use the inherited (overloaded) version. > > So, Ada dispatches to a more general operation by default rather > than to a more specific one. This is the wrong way round, IMO. I How did you arrive at that conclusion?? No, it simply dispatches to the operation for which the arguments are intended. If it is to the more general, well then that is because the operands passed _are_ of the more general type! > think calling a more general operation ought to be the exception > rather than the default. Some will not agree with me but that's > okay. :) Well, I disagree, because you are just plain factually wrong. > I *am* saying that because Eiffel is covariant, you don't have to > re-invent an operation as an overloaded operation due to inheriting > some unwanted baggage that no longer reflects the specialisation of > an abstraction. No, you are not "re-inventing" anything. You aren't overloading for those reasons at all. You overload because a) the inherited operation is not refined in the "other" parameter and that is what you want and b) using a different name for the operation is confusing, misleading, and leads to poor software maintenance. Which simply says, you can have your cake (complete safety) and eat it too (give the programmer model the functional equivalence of unbroken covariance). -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com