Python from Wise Guy's Viewpoint

[Joachim Durchholz]

Marcin 'Qrczak' Kowalczyk wrote:

> On Sun, 19 Oct 2003 20:01:03 +0200, Joachim Durchholz wrote:
> 
>>The longer answer: Multimethods have modularity issues (if whatever domain
>>they're dispatching on can be extended by independent developers:
>>different developers may extend the dispatch domain of a function in
>>different directions, and leave undefined combinations;
> 
> This doesn't matter until you provide an equally powerful mechanism which
> fixes that. Which is it?

I don't think there is a satisfactory one. It's a fundamental problem: 
if two people who don't know of each other can extend the same thing 
(framework, base class, whatever) in different directions, who's 
responsible for writing the code needed to combine these extensions?

Solutions that I have seen or thought about are:

1. Let the system decide. Technically feasible for base classes (in the 
form of priorisation rules for multimethods), technically infeasible for 
frameworks. The problem here is that the system doesn't (usually) have 
enough information to reliably make the correct decision.

2. Let the system declare an error if the glue code isn't there. 
Effectively prohibits all forms of dynamic code loading. Can create 
risks in project management (unexpected error messages during code 
integration near a project deadline - yuck). Creates a temptation to 
hack the glue code up, by people who don't know the details of the two 
modules involved.

3. Disallow extending in multiple directions. In other words, no 
multimethods, and live with the asymmetry.
Too restricted to be comfortable with.

4. As (3), but allow multiple extensions if they are contained within 
the same module. I.e. allow multiple dispatch within an "arithmetics" 
module that defines the classes Integer, Real, Complex, etc. etc., but 
don't allow additional multiple dispatch outside the module. (Single 
dispatch would, of course, be OK.)

5. As (3), but require manual intervention. IOW let the two authors who 
did the orthogonal extensions know about each other, and have each 
module refer to the other, and each module carry the glue code required 
to combine with the other.
Actually, this is the practice for various open source projects. For 
example, authors of MTAs, mail servers etc. cooperate to set standards.
Of course, if the authors aren't interested in cooperating, this doesn't 
work well either.

6. Don't use dynamic dispatch, use parametric polymorphism (or whatever 
your language offers for that purpose, be it "generics" or "templates").

Regards,
Jo