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/08 Message-ID: #1/1 X-Deja-AN: 195369533 sender: news@organon.com (news) references: organization: Organon Motives, Inc. newsgroups: comp.lang.eiffel,comp.lang.ada Date: 1996-11-08T00:00:00+00:00 List-Id: In article donh@syd.csa.com.au (Don Harrison) writes: > Robert I. Eachus writes: > > :significant. It is a very useful feature to be able to instantiate a > :generic in a scope and inherit the local statically enclosing > :definitions of certain operations. It is even more useful that the > :operations are selected based on the name of the function AND the > :parameter and return value profile. You not only get the local > :operator, you get the right version to match the other generic > :formals. > > Okay but the problem I have with this is that picking up the local stuff > implicitly as parameters to the instantiation is potentially confusing > (as your example demonstrates). What would be clearer and less confusing, > IMO, would be to declare the parametric information in a type together with > the operation so that when you instantiate (explicitly) with that type > (or a descendant type), you get the right operation with it. This way, it's > very plain what the actual instantiation parameters are. > > Not sure how you would write this in Ada. Maybe (excuse the syntax errors) That's one of the "typical" uses for generic formal package parameters. It is one of the reasons they were included. generic type Some_Type is tagged private; with function Some_Op (...) return Some_Type; package X is end X; generic with package IX is new X(<>); -- No added constraints on Inst. of X procedure Generic_Op(...); package IX is new X(My_Type); procedure Actual_Op is new Generic_Op(IX); An obvious variant that may prove useful in making sure things "line up" correctly would be: generic type Some_Type is new My_Type with private; with package IX is new X(Some_Type); procedure Generic_Op(...); Here, any supplied instance for IX must have been obtained via My_Type or one of its descendants. /Jon -- Jon Anthony Organon Motives, Inc. Belmont, MA 02178 617.484.3383 jsa@organon.com