Re: Is the Writing on the Wall for Ada?

[aek@vib.usr.pu.ru (Alexander Kopilovitch)]

olehjalmar kristensen wrote:

>     AK> Combining different roles in the same object may be a good thing
>     AK> as far as those roles do not interfere with each other.
>     AK> But in reality they may interfere by subtle and unforeseen way,
>     AK> in some singular points of the problem space. Therefore it is
> 
> Of course, that's why I said you needed some care. However, in
> practice, there will be little or no overlap, and thus little chance of
> interference, precisely because you have modeled the different roles
> properly. Also, you will typically use multiple virtual inheritance
> via one common base class to allow the different roles to interact.
> I'm talking about multiple inheritance as a tool for combining
> carefully modeled, largely orthogonal roles in a single object, not as
> a tool for grabbing whatever functionality happens to be in some class.

Well, perhaps you are careful enough with these things, and aren't
subjected to temptation "to grab whatever functionality happens to be
in some class". But most programmers and software engineers surely
have insuffiencet resistance to that temptation, and succumbed to it
more or less often (as experience with *real* C++ programs shows quite
clearly).

So, it is important to differentiate both the need for and dangers of
combining roles this way between the primarily modelling/simulation
class of applications and the class of applications that are in close
contact with real world (that is, with real objects and in real time).

What you wanted is *symmetrical* combining roles. That symmetry indeed
often happen in abstract models and may be very useful feature (and even
a fundamental feature of the model); therefore it will be good to express
this symmetry clearly and directly in source code. At the same time
the risks associated with an unforeseen interference between the roles
is relatively low, because the results of computation usually aren't
applied immediately, but will be analyzed and interpreted by trained
people in usually calm environment.

But for the applications that are in close contact with real world,
the situation is opposite. First, symmetry simply *never* exists
in real world. Quite strong statement, isn't? A symmetry may appear
as a satisfactory approximation in some conditions, which may emerge
and disappear occasionally. Nobody can guarantee any symmetry for a
particular small event in real world. Even a strong probablistic
estimate for such a symmetry seems to be very rare possibility.
Furthemore, even if we are able to prove that the conditions for
symmetry (of roles) will be present then the next question is: how
stable are our assumptions? Will they be still in place, say, 5 years
ahead? (If you disagree with all that just said then please provide
a counterexample - a pair of symmetrical real-world roles.)
Now let's observe the risks associated with a conflict bewteen those
"pseudo-symmetrical" roles. I think it is obvious enough that the risks
are generally much higher here, just because our applications can cause
immediate effects in the real world.

So, a feature for (symmetrical) combining roles in Simula-67 was fully
justified, while for Ada it seems undesirable.

> Sure, you can always use delegation, and obtain precisely the same
> interface to the object as if you had used multiple inheritance. But
> then you are really just implementing it yourself. I can do that in C
> too. No need for inheritance at all, really. I actually did this in a
> project in the early eighties as we only had C, not Simula or some
> other object oriented language available on our Unix system.

Well, but basic delegation (and you need not more, if you want multiple
inheritance, but do not expect from a compiler any complex specifics)
may be implemented using canonical way; so you may develop a custom
preprocessing tool (perhaps, using ASIS, if you wish a full-scale tool).
and have Ada-MI (with file extension .ami -:) ... those who are unable
to create such a tool for themselves surely do not deserve multiple
iheritance in Ada -:) . You may also put this tool in public domain,
and if it becomes highly popular then it may eventually convince ARG
to reconsider their view on the subject... not for Ada200Y, but perhaps
for Ada201Z -:) .



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia