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: Eiffel and Java + Ada dispatching Date: 1996/11/05 Message-ID: #1/1 X-Deja-AN: 194566672 sender: news@organon.com (news) references: organization: Organon Motives, Inc. newsgroups: comp.lang.eiffel,comp.lang.ada Date: 1996-11-05T00:00:00+00:00 List-Id: In article donh@syd.csa.com.au (Don Harrison) writes: > I was able to infer from your note why Ada you cannot break > polymorhism. (Broken polymorphism is the problem in Eiffel - System > Validity it's solution). The reason is that Ada is avariant - when > overriding dispatching operations, you cannot redefine > non-dispatching parameters covariantly. Right. But part of the story for _how_ this is, is overloading. > eg. Assuming type B descended from A and Q descended from P, > > 1. procedure op (a: A; p: P'Class); -- dispatches on a > ... > 2. procedure op (b: B; p: P'Class); -- dispatches on b (overriding op above) Right. > But, as you point out below, a dispatching operation that has the > same signature as another but a different non-dispatching parameter > does not override the original, so cannot be called polymorphically > wrt the original. Right - it is an _overloading_ definition of the _specific_ types involved. > 3. procedure op (b: B; p: Q'Class); -- dispatches on b (distinct > -- operation from 1. above - does > -- not override it). Right. > What we can see from this is that overriding in Ada is implied (by > the combination of descendant dispatching parameter, same > non-dispatching parameter) rather than being explicit as in Eiffel > (redefine clause). Right (note that "parameter" for each sort may be plural). > :The reason that OL enters into the puzzle is that it allows for the > :definition of _new_ operations (on specific types) with descendent > :controlling parameter(s) and a _non_ controlling descendent > :parameter(s) but with the same name. Now you can claim that this is > :"confusing" (a value judgement), but that will most likely be because > :you are not used to the differentiation between specific types and > :class-wide types ... > > Yes. I agree this may be confusing to some. I was one of them. :) > Personally, if writing Ada, I would prefer to use a different name rather > than overloading the old one to remove all confusion. OK. But then you lose some of the functionality. Basically the OL lets you have the "covariant" thingy, but forces you to supply the exact definition for each possible such case. > 4. procedure new_op (b: B; p: Q'Class); -- dispatches on b Yes, but now this is not related to Op (in the sense I mention just above). /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com