Re: Real OO

[cjames3@concentric.net (The Right Reverend Colin James III)]

Stop posting this crap to comp.lang.eiffel
--------------------------------------------------------------
amitp@Xenon.Stanford.EDU (Amit Patel) posted with deletions:

|  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


~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Re-usable, patented software for banks and financial markets. 
Mirror sites:  www.cec-services.com  &  www.cris.com/~cjames3
Colin James III, Principal Scientist, cjames@cec-services.com
CEC Services, LLC, 2080 Kipling St, Lakewood,  CO  80215-1502
Voice: 303.231.9437;  Facs: 303.231.9438;  Data: 303.231.9434
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~