Re: Modularity problems with multiple dispatch

Rainer Joswig schrieb:
Joachim Durchholz <jo@xxxxxxxxxxxxx> wrote:

Marcin "Qrczak" Kowalczyk schrieb:
>>
Joachim Durchholz pisze:
>>>
Find all appropriate f based on A' (L1) , using the CLOS precedence
rules for inheritance etc. Do the same for B' , based on L1.
You will have a candidate f, or not (error) .
>>>>
Yes, but it will sometimes not be the right one.
>>>
But it usually is the right one, because usually there exists a single
most specialized method.
>>>
Note the use of the word "usually".
Which means that there are cases where there does not exist a single most specialized method, and cases where not the right one is chosen.

CLOS is not about 'the single specialized method'. At runtime
a so-called 'effective method' is run, which is compute
from the ordered set of applicable methods, by using
a so-called 'method combination'. An effective method
may be build out of several methods - with possibly
different roles.

Yes, that's even worse: simply run all the various inherited methods one after the other, hoping that the result will magically "do the right thing". (In many cases, it will. In others, it won't. You won't get a warning. And the bug can emerge when combining two libraries that are correct in isolation. Not what I'd want in a language.)

CLOS has two ways to deal with the possibility that
the programmer might not like the defaults:

1) you can implement your own inheritance rules

Fixing a bug that emerges from combining two third-party libraries. Doesn't sound like everyday application programming to me.

2) using method combination let's you choose different ways
to compute the effective method. The developer
can create own method combinations. DBC (Design
by Contract) for example can be introduced
by a method combination (plus some other machinery).

Assertions can help, but they cannot capture all aspects of a function's behaviour under run-time dispatch.
(This problem vanishes if you drop either mutability or run-time dispatch. IIRC Lisp in its various forms is the only FPL that still relies heavily on both.)

CLOS favors flexibility and using generic functions in CLOS
means for the programmer that he/she should be prepared to
not (!) know at compile-time what code will run at runtime
and how this code is combined.

If he doesn't know how the code is combined, he doesn't know what combinations with emergent bugs will happen.

That's a sure recipe for the odd combination of circumstances with disastrous results.

Regards,
Jo
.

Relevant Pages

  • Re: Stroustrups FAQ causes infinite loop when executed
    ... There may be ways in which inheritance could ... programmer could not have foreseen. ... >> complex calculations such as multiplying numerous transformation ... >> reason to cap the class. ...
    (comp.lang.cpp)
  • Re: Object Oriented simpleton design pattern
    ... makes me believe that Inheritance and Polymorphism are the joint ... For reuse without any changes, ... functions but rather functionality. ... Implemenation inheritance is simply a means where a programmer can instruct ...
    (microsoft.public.vb.general.discussion)
  • Re: Modularity problems with multiple dispatch
    ... rules for inheritance etc. Do the same for B', ... a so-called 'effective method' is run, ... behaviour under run-time dispatch. ... Lisp isn't really a FPL anyway. ...
    (comp.lang.functional)
  • Re: Modularity problems with multiple dispatch
    ... rules for inheritance etc. Do the same for B', ... The programmer who tries to call f? ... Then the situation degenerates into single dispatch, and for that, we can use DbC and don't have that combination problem. ... my definition of an FPL is one that allows you to construct functions at runtime. ...
    (comp.lang.functional)
  • Re: Why cant C# or Java support multiple inheritance? But inherit multiple interfaces instead??
    ... > has terrible support for inheritance in general, ... programmer specify what specific class definition to use, ... > Funny, I don't seem to get them in Eiffel, which supports complete ... and recurring kinds of collaborations between those domain entities and ...
    (comp.object)