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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,49aef7ebb96f8048,start X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,2ea02452876a15e1 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,c52c30d32b866eae X-Google-Attributes: gid1108a1,public X-Google-Thread: 1014db,49aef7ebb96f8048,start X-Google-Attributes: gid1014db,public From: cjames3@concentric.net (The Right Reverend Colin James III) Subject: Re: Real OO Date: 1996/05/07 Message-ID: <318fd8c9.4369392@news.concentric.net>#1/1 X-Deja-AN: 153675144 references: <4j9p3a$uo5@watnews1.watson.ibm.com> <4kbqun$iiv@watnews1.watson.ibm.com> <6850x6pV3RB@herold.franken.de> <4moh63$i0b@nntp.Stanford.EDU> organization: CEC Services, LLC reply-to: cjames3@concentric.net newsgroups: comp.lang.ada,comp.object,comp.lang.c,comp.lang.c++ Date: 1996-05-07T00:00:00+00:00 List-Id: Stop posting this crap to comp.lang.eiffel -------------------------------------------------------------- amitp@Xenon.Stanford.EDU (Amit Patel) posted with deletions: | Joachim Durchholz 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 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~