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