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: amitp@Xenon.Stanford.EDU (Amit Patel)
Subject: Re: Real OO
Date: 1996/05/07
Message-ID: <4moh63$i0b@nntp.Stanford.EDU>#1/1
X-Deja-AN: 153572921
references: <4j9p3a$uo5@watnews1.watson.ibm.com> <DpBsG4.MIE@assip.csasyd.oz>
 <4kbqun$iiv@watnews1.watson.ibm.com> <6850x6pV3RB@herold.franken.de>
organization: Computer Science Department, Stanford University.
newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object
Date: 1996-05-07T00:00:00+00:00
List-Id: <comp.lang.ada>


 Joachim Durchholz <jhd@herold.franken.de> wrote:
>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.  

(about the loss of independence of classes/modules)  Agreed.

>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.

The combinatorial explosion is for *potential* definitions, but in
most designs, it won't actually occur.  You'll either write lots of
new code for existing classes (reuse of classes) or write lots of new
classes for existing code (reuse of code).  (In the dictionary's
lookup matrix, you'll get columns or rows, but not a dense matrix.)

The problem is that you can't assume it will *never* occur.  In cases
that it does, multiple dispatch is great!  :) If the problem requires
A x B different pieces of code, then you're going to have to put A x B
pieces of code in your program, whether you have multiple dispatch or
not.  Having multiple dispatch as a solution technique makes it much
(?) easier to write your program when the problem you're solving
requires it.

I'm much more comfortable with languages that don't force me to use a
multiple dispatch paradigm, for the reasons you've stated, but I'm
convinced that the design patterns *don't* work in all cases, and
multiple dispatches really is needed in some cases.  Having this
feature as an option would be nice.  (I'd only use it when the matrix
is fairly dense.)



	-- Amit