Re: Is the Writing on the Wall for Ada?

[Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>]

On Tue, 23 Sep 2003 12:49:41 +0200, Jacob Sparre Andersen
<sparre@crs4.it> wrote:

>Ole-Hjalmar Kristensen wrote:
>>>>>>>"JSA" == Jacob Sparre Andersen <sparre@crs4.it> writes:
>>     JSA> Olehjalmar Kristensen wrote:
>>     >>>>>>> "RIE" == Robert I Eachus <rieachus@attbi.com> 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