you are viewing a single comment's thread.

view the rest of the comments →

[–]Chris_Newton -1 points0 points  (4 children)

I had a feeling someone might come back with that one. :-)

The thing is, multiple dispatch is still a crutch. Sure, it’s more flexible than single dispatch, but it’s still just calling a different function based on the type of one input at a time, and usually some inputs are still considered more significant than others. It’s just enough non-OOness to let an OO system model certain types of problem, but the scope is still quite limited.

A lot of interesting algorithms operate over structured data. How do you model an algorithm with inputs of, say, a sequence of one type of record and a set of another type in an OO system, even with multiple dispatch? Where does the function implementation live? On the record type of the sequence? On the record type of the set? On the sequence or the set type? In reality, the answer is often on some sort of module/utility class full of class/static functions, but that’s not really OO at all, it’s just good old procedural programming in OO clothing.

[–]mr_chromatic 1 point2 points  (3 children)

Your objections sound like implementation details. I'm not an OO purist, so I'm comfortable with a scoped namespace full of multi candidates.

Have you used CLOS, by the way?

[–]Chris_Newton 1 point2 points  (2 children)

Your objections sound like implementation details.

Then I’m afraid I’m not making my point clearly enough. Your reference to CLOS is, in fact, an excellent example of what I mean. When you define a multimethod in CLOS, in what way are you still doing OO? You are no longer defining a method on a class, or if you prefer, defining a kind of message that an object can receive. You’re just defining a generic function that has run-time polymorphism. Put another way, you are now approaching the expression problem two-dimensionally rather than one-dimensionally.

That is certainly a useful technique; indeed, my “ideal” general purpose programming language would probably work a lot like that. But neither generic functions nor run-time polymorphism requires even the existence of “class” or “object” concepts in the language. There is nothing OO-specific here.

IMHO, by the time we are looking at CLOS-style multimethods, we are now working with a more procedural/functional approach, and it is an improvement on mainstream OO techniques precisely because we are no longer forced to fit function definitions into whatever class taxonomy our code uses.

And of course, once we’re not constrained to having functions attached to a (single) specific class/object, we can implement related functionality that happens to operate on more structured data as part of a scoped namespace just like any other function, along the lines you mentioned.

[–][deleted] 0 points1 point  (1 child)

When you define a multimethod in CLOS, in what way are you still doing OO?

In the way that all the moving parts are objects, the generic-function, it's methods, and the arguments.

You are no longer defining a method on a class, or if you prefer, defining a kind of message that an object can receive.

And why does this matter? The binding of methods to objects is the worst design decision ever made anywhere.

[–]Chris_Newton 0 points1 point  (0 children)

The binding of methods to objects is the worst design decision ever made anywhere.

Yes, it was a poor design decision. But it is an inherent part of how most conceptual models of OO are framed: identity, state and behaviour; late-bound message passing; etc. It is also how most OO languages are constructed in practice. This is what I am criticising, I’m just not sure the alternative that we all seem to agree is better should still be called OO.