Re: Real OO

[donh@syd.csa.com.au (Don Harrison)]

Amit Patel writes:

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