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: 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: donh@syd.csa.com.au (Don Harrison) Subject: Re: Real OO Date: 1996/05/08 Message-ID: #1/1 X-Deja-AN: 153691763 sender: news@assip.csasyd.oz references: <4moh63$i0b@nntp.Stanford.EDU> organization: CSC Australia reply-to: donh@syd.csa.com.au newsgroups: comp.lang.eiffel,comp.lang.ada,comp.object Date: 1996-05-08T00:00:00+00:00 List-Id: Amit Patel writes: : Joachim Durchholz wrote: :>2) Combinatorial explosion. [...] :>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. This would be true if it were mandatory to provide an implementation for every possible parameter combination. Of course, if that were so, you would hope developers would control it voluntarily by avoiding it. Pity the person who didn't. :-( This would be done by freezing parameters. For example, instead of f (a: A; b: B; c: C) -- triple dispatched treat c generically: f (a: A; b: B; c: frozen C) -- double dispatched or, treating b and c generically; f (a: A; b: frozen B; c: frozen C) -- single dispatched. A mathematical analogy might be that of partial differentiation. BTW, this suggests that the defaults should be reversed. That is, parameters should be frozen (classwide) by default and dispatching parameters should be explicitly declared as such. The above might become: f (a: *A; b: *B; c: *C) -- triple dispatched f (a: *A; b: *B; c: C) -- double dispatched f (a: *A; b: B; c: C) -- single dispatched. That should confuse the C/C++ fraternity. :-) :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. Agree. Simulating it using single dispatching would be awkward. :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.) One way of controlling both the ambiguity and combinatorial explosion problems would be to only require that an implementation be provided if actually used. That is, if a call is made with a specific combination of actual parameters. If this can be determined statically (difficult), then it could be required as a static constraint for a statically typed language. If not, then it could be imposed as a dynamic constraint for both statically and dynamically typed languages. In this case, an exception would be raised if the specific implementation corresponding to a parameter combination is not found. I think I prefer the dynamic approach. In the context of Ziggy, failure to dispatch as a result of broken multiple dispatching would simply be another manifestation of broken polymorphism. System level validity checking would be a runtime phenomenon. : : -- Amit /// Don. (o o) =-=-=-=-=-=-=-=oOO=-(_)-=OOo=-=-=-=-=-=-=-=- Don Harrison donh@syd.csa.com.au