Re: [boost] Re: MultiMethod/Visitor Interest

From: Jesse Jones (jesjones_at_[hidden])
Date: 2004-09-28 19:30:50

On Sep 28, 2004, at 9:13 AM, Danil Shopyrin wrote:

> Background. My solution is an "idealized" solution. It is stands as an
> answer to question: "can multimethods be implemented in C++ using only
> 'good' programming techniques?" It is fully compile time and 
> absolutely type
> safe. And there is no of RTTI. This is an academic result. Moreover, 
> this is
> ready to practical use (I do it).

Well, what is ideal is in the eye of the beholder and many people seem 
to approach multimethods from a rather pinched perspective. Many 
developers seem to take them at face value and consider them as a tool 
for handling those rare (but annoying) cases where you need to dispatch 
on multiple types. Things like intersection or collision tests.

I think of them differently: as a complement to the dynamic dispatch 
performed by virtual functions. The difference is that multimethods 
allow dynamic methods to be added without disturbing the class which is 
invaluable if you can't edit the class or don't want to load it up with 
methods that are used in only a few places in the code. Secondarily, 
they also allow dispatch using multiple types which opens up the 
possibility for non-traditional solutions to icky things like event 
dispatching in GUI frameworks.
>
> Further, about drawbacks:
>
> 1) Compile time. Yes, this solution is strongly compile time.
>    But I think it is an advantage :-)

I disagree. The biggest benefit of multimethods is that they are 
flexible. If you wire in all the methods at compile time you lose a 
great deal of that flexibility. In particular frameworks can't provide 
customizable multimethods to clients: designers are either forced to 
abandon multimethods or require users to wire them up even if most of 
the behavior is stuff that should be defined in the framework.
>
> 2) You are right. There is no "next_method". I was never think of them.

Well, they aren't needed for simple use cases. But they seem quite 
valuable in more complex scenarios.
>
> 3) Intrusive. It is eliminated.

It still requires user classes to be designed with multimethods in mind 
though. Each class that is dispatched upon needs a visit method which 
is a pretty annoying restriction.
>
> 4) "distinguishes the first argument". It is eliminated.

Good. :)
>
> 5) Gnarly user code. Look at up-to-date "tiny use case" at
>    http://sdanil.narod.ru/mm/m2vd3_v5.zip
>
Which file are you talking about?

   -- Jesse