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,c52c30d32b866eae
X-Google-Attributes: gidfac41,public
X-Google-Thread: 103376,2ea02452876a15e1
X-Google-Attributes: gid103376,public
X-Google-Thread: 1108a1,c52c30d32b866eae
X-Google-Attributes: gid1108a1,public
From: jhd@herold.franken.de (Joachim Durchholz)
Subject: Re: Real OO
Date: 1996/05/02
Message-ID: <6850x6pV3RB@herold.franken.de>#1/1
X-Deja-AN: 153152555
distribution: world
references: <4j9p3a$uo5@watnews1.watson.ibm.com>
newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object
Date: 1996-05-02T00:00:00+00:00
List-Id: <comp.lang.ada>


ncohen@watson.ibm.com wrote 08.04.96 on Re: Real OO:

> I have nothing against Eiffel, and my background in formal methods makes
> me especially appreciative of the Eiffel approach to formalizing
> inheritance, but I find the Ada model of dispatching less error-prone and
> more flexible.

As I understand it, you mean the multiple dispatching mechanisms  
(a.k.a. classwide operations).

While I agree that these can be useful, I noted a few problems  
that can arise in this context:

1) Ambiguity of routine to be called.
Consider the following situation: I have two classes A and B that  
each have a descendant A' and B', respectively.
Now let's define a class-wide function (just class names in the  
parameter list)
  f(A, B)
meaning whenever f is called, parameters my be of class A and its  
descendants resp. B and its descendants.
When I write an additional function
  f(A', B) -- redefinition 1
any calls to f that have their first parameter of class A' (or  
further down the inheritance chain) will get to call this version  
of f.
Likewise, a function
  f(A, B') -- redefition 2
will do the same for B'.
But which of these gets called if the parameters are of type A'  
*and* B'? Both functions are applicable, redefinition 1 and  
redefinition 2.

You can add disambiguating rules, of course, like giving  
precedence to the first parameter.

But this trades ambiguity for obscureness. Imagine a developer  
who has introduced redefinition 2, tested it, and put to  
productive use.
Later (read "years later"), a different programmer introduces  
redefinition 1, which will override redefinition 2. So suddenly  
lots of code will have a different meaning, at places that I  
suspect can't easily be spotted.
I.e. this tightens the coupling between two classes.


2) Combinatorial explosion.

The number of possible class-wide functions is (number of  
descendants of A) times (number of descendants of B)  
("descendant" including the class itself here).

This explosion may not be visible in the source code; however,  
this appearance is deceiving. After all, even if there is no code  
necessary for most of the combinations, you have to check *all*  
of the combinations and look wether an overriding class-wide  
function is necessary.

Even worse, classes cannot be viewd as independent entities  
anymore. Whenever a new class is added, all combinations with all  
classes for wich a multiply dispatching routine is defined have  
to be reviewed. [Sarcasm (sorry) on] I consider this a good  
scenario for a horror story... but not for software development.  
[Sarcasm off]


3) It seems unnecessary.

Some of the Design Patterns explicitly address such combinatorial  
explosions and give a solution. None of the solution employs  
multiple dispatching. (This may be more due to the fact that it  
evolved from single-dispatching language tradition, of course.)


Conclusion

I'm not expert enough to actually determine wether the available  
design patterns will work in every case.

However, the combinatorial explosion effect makes me more than  
reluctant to accept multiple dispatching as a desirable feature,  
even if it is useful in special cases. And I suspect any solution  
that controls this explosion also opens an avenue to designing a  
single-inheritance class hierarchy.

-Joachim

--
Im speaking for myself here.