Re: Is the Writing on the Wall for Ada?

["Robert I. Eachus" <rieachus@attbi.com>]

Ole-Hjalmar Kristensen wrote:
>>>>>>"JSA" == Jacob Sparre Andersen <sparre@crs4.it> writes:
>>>>>
> 
>     JSA> Olehjalmar Kristensen wrote:
>     >>>>>>> "RIE" == Robert I Eachus <rieachus@attbi.com> writes:
> 
>     RIE> interfaces  and mix-ins.  But  type inheritance  cannot  be from  two
>     RIE> concrete parents,  no matter what  the language--one parent has  to be
>     RIE> abstract. So  anyone who condemns Ada  for not adding  what cannot be
>     RIE> done needs to get a life.
>     >> What do you mean by "concrete parents"?
> 
> 
>     JSA> Although  I agree  that  "non-abstract parents"  is  the most  obvious
>     JSA> interpretation   of   "concrete   parents",   I   understood   it   as
>     JSA> "data-containing non-abstract parents".

I would say that two non-abstract parents without data is a special case 
I was ignoring.  You have a potential problem if two concrete types have 
  different state data, or identical states with different meanings.

> I understand now, by see below.

Exactly.  The Ada "workarounds" for this issue are the same.  If you 
want to inherit from two parents which both access the same state data, 
you can push the state to a common parent.  If the states are 
independent, you can use mix-ins that add state, but only see their own 
state variables.  Or if you need for one class to see the other's state 
but not vice-versa, you can import the methods of one parent class into 
the min-in for the other.  But if you want to inherit from two classes 
with state, and adjust the state of each based on changes to the other, 
the na�ve implementation isn't possible in Ada, and causes indefinite 
recursion in C++.  In C++ you can compile it, but unless you break the 
recursion, you can't run it.  In Ada you can't compile some versions 
without breaking the recursion.  That doesn't say you can't write 
indefinite recursion or infinite loops to implement this "abstraction" 
in Ada.  It is just that there are some implicit cases that are not allowed.


Back to the example of polar and cartesian co-ordinates.  It is possible 
to do things so that the Get operations are all inherited from the 
respective classes, but the Set operations have to be overridden for the 
child class--and carefully so you don't do unintended recursion.  (To do 
it without adding additional operations or state is possible, but left 
as an exercise for the reader, in Ada or C++ whichever you prefer.  And 
please, don't post it.  The practical solution does add extra state and 
uses lazy evaluation of the conversions between types.)

So as usual, the IDEA of multiple inheritance is powerful.  But in any 
case where you try to take advantage of "true" MI, there are 
implementation specific issues to be resolved.  So why is MI theory so 
common?  Because it is such a nice formalism for use in preliminary 
design.  I can say that this dataset is a list and it is a indexed 
array.  During  detailed design, I can choose the actual abstraction 
used to implement the dataset for performance reasons, which could be an 
indexed file, or a B-tree.

-- 
                                        Robert I. Eachus

Ryan gunned down the last of his third white wine and told himself it 
would all be over in a few minutes.  One thing he'd learned from 
Operation Beatrix: This field work wasn't for him. --from Red Rabbit by 
Tom Clancy.