Re: What databases have taught me
Date: 30 Jun 2006 00:32:11 -0700
> Marshall wrote:
> > A fair point. I remain sceptical about multimethods in particular, but
> > I agree in general. (I wonder: if a language lacks subtyping, and
> > has overloading, is there anything left for multimethods to do? Hmmm.)
> I think multimethods are essential for system extensibility, and
> essential to proper polymorphic behavior (which is about the only
> useful, albeit usually poorly-implemented, feature of O-O).
> Predicate-based dispatch (aka pattern matching?) is, to me, the logical
> extension of the concept.
I don't see how multimethods help with extensibility.
Imagine a matrix of operations x data types. We can consider extensibility in either the operations, or in the data types.
OO makes extending the data types easy, and extending the operations hard. If you add a new class to an existing interface, you can do so modularly, in that no other class is affected, and similarly, existing code can make use of the new class without modification. However, if you want to add a new method to the interface, you have to update *every* class. Note also that OO classes are a kind of open union type.
FP makes extending the operations easy. Write a new method that works on every data type, and you don't have to modify any existing code. Your new code can pattern match on the data types. However, if you want to add a new data type, you have to modify every existing function. Note that FP union types are a kind of closed object class.
What do multimethods buy you? If programmer x entends the operations, and programmer y extends the data types, who is going to write the code that implements x's operator on y's data type? This problem is a fundamental one; it cannot be solved by language featues.
Marshall Received on Fri Jun 30 2006 - 09:32:11 CEST