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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1116ece181be1aea X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-23 06:49:24 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!fu-berlin.de!uni-berlin.de!tar-alcarin.cbb-automation.DE!not-for-mail From: Dmitry A. Kazakov Newsgroups: comp.lang.ada Subject: Re: Is the Writing on the Wall for Ada? Date: Tue, 23 Sep 2003 15:57:46 +0200 Message-ID: References: <3F5F7FDC.30500@attbi.com> <3F6079A9.6080108@attbi.com> <3F60E380.4020307@attbi.com> <3F694186.5060709@crs4.it> <3F702545.6080704@crs4.it> NNTP-Posting-Host: tar-alcarin.cbb-automation.de (212.79.194.111) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: news.uni-berlin.de 1064324962 4293885 212.79.194.111 (16 [77047]) X-Newsreader: Forte Agent 1.8/32.548 Xref: archiver1.google.com comp.lang.ada:42803 Date: 2003-09-23T15:57:46+02:00 List-Id: On Tue, 23 Sep 2003 12:49:41 +0200, Jacob Sparre Andersen wrote: >Ole-Hjalmar Kristensen wrote: >>>>>>>"JSA" == Jacob Sparre Andersen writes: >> JSA> Olehjalmar Kristensen wrote: >> >>>>>>> "RIE" == Robert I Eachus writes: > >> JSA> Looks that way to me too. But if a and b had contained data, for >> JSA> example position data in respectively spherical and rectangular >> JSA> coordinates (to reuse an earlier example), then you would most likely >> JSA> end up in trouble. > >> Depends on what you expect. As you can see, there is no conflict as >> such. On the other hand, a and b can not access each others variables >> either. > >That was not really what I was worrying about either. I couldn't even >imagine that somebody would design a language that would allow a and b >to access each others variables. > >It was more the problem of inconsistencies due to duplicated data with >the same interpretation: > > type Complex_Polar is private; > function Argument (Item : in Complex_Polar) return Scalar; > [...] > > type Complex_Rectangular is private; > function Arg (Item : in Complex_Rectangular) return Scalar; > [...] > >private > > type Complex_Polar is record Modulus, Argument : Scalar; end record; > type Complex_Rectangular is record Im, Re : Scalar; end record; > >If we made a new type inheritede from both of these two (yes, I didn't >write that they are tagged), the results of the two functions Argument >and Arg (which I at least would want to be the same) would not >neccessarily be the same. You didn't express your wish in langauge terms. So why do you blaim MI for this? Should both functions be same, you have to show this. For example: type Abstract_Complex is abstract ...; function Arg (Item : Abstract_Complex) return Scalar is abstract; type Complex_Polar is new Abstract_Complex with ...; function Arg (Item : Complex_Pola) return Scalar; type Complex_Rectangular is new Abstract_Complex with ...; function Arg (Item : Complex_Rectangular) return Scalar; Now any attempt to derive from both will reveal a conflict in two implementations of Arg. This conflict is good here. In your example, it forces you to provide a consistent implementation of Arg for the new type. If such does not exist, it is not a problem of MI, or? Alternatively, if you inherit from, say List_Element twice, via different routes. The conflict is again good. It forces you to choose whether object of the new type has to be an element of exactly one list or of two of them. And again, neither the conflict itself nor the way it is resolved are MI problems. >> In the general case I agree, there may be problems, but I think that >> the compiler rejecting cases it cannot resolve properly is quite acceptable. > >I am not sure that is sufficient for me. But the above case _would_ >most likely be resolved properly by the compiler (because I didn't give >both the functions the same name) and thus lead to unneeded confusion. If you declare two varaibles which has to be same, how to avoid this unneeded confusion? Right, one should not allow multiple variable declarations! --- Regards, Dmitry Kazakov www.dmitry-kazakov.de