Prev: Modularity problems with multiple dispatch
Next: MVC again, this time the code [C++]
From: Marshall on 12 Nov 2007 15:26
On Nov 11, 3:03 pm, Joachim Durchholz <j...(a)durchholz.org> wrote:
> Marshall schrieb:
>
> > Very interesting. Can you expand on the difficulties that multiple
> > dispatch brings to the question of composable modules?
>
> Assume you have a multi-dispatching function
>
> f (A, B)
>
> Now the author of class A creates a subclass A', and the associated function
>
> f (A', B)
>
> Likewise for the author of B:
>
> f (A, B')
>
> Problems arise if the two authors don't know about each other (or can't
> or don't want to collaborate). Then, combining classes A' and B' in one
> system will lack a definition for
>
> f (A', B')

Okay. This is the same thing as the "expression problem", yes?
But it seems to me the situation is actually better with multiple
dispatch than it is with OOP. Or am I imagining that? It seems
that again the problem is mutability, not multiple dispatch.

If we are really asserting:

A' <: A
B' <: B
the extension of f(A', B) is a subset of the extension of f(A, B)
the extension of f(A, B') is a subset of the extension of f(A, B)

Then if we have a:A' and b:B', it doesn't matter which one
of the three f's we call; they all produce the same answer.

However in practical terms, we don't have expressive enough
languages to capture enough semantics, as you've said I think.


> There are several ways to deal with the situation:
>
> 1) Give priority to one of the parameters (usually the first one). This
> means f (A', B') defaults to f (A', B). This can cause problems if the
> implementations of A' and B' are so different from their respective base
> classes that f (A', B') really would have to be written.

Why must it be written? Efficiency?


> 2) Force the integrator to write f (A', B'). Extra bonus if he doesn't
> have the sources of A' and B'.

Ha ha, yes.


> The "nonmodular" bit comes from the observation that A' and B' aren't
> modules anymore: they cannot be added independently, there's an
> interaction between them.

It appears to me there is only an interaction if the authors of the
specialized f's have broken the semantics of subtyping, yes? In
other words, there is only an interaction if the various f()s that
are supposed to have a particular semantic relationship don't.

It seems this semantic equivalence is undecidable, though. :-(


Marshall

 | 
Pages: 1
Prev: Modularity problems with multiple dispatch
Next: MVC again, this time the code [C++]