[boost] Re: MultiMethod/Visitor Interest

From: Alexander Nasonov (alnsn_at_[hidden])
Date: 2004-09-30 00:17:56

David Abrahams wrote:
> Alexander Nasonov <alnsn_at_[hidden]> writes:
> 
> > David Abrahams wrote:
> >> Jesse Jones <jesjones_at_[hidden]> writes:
> >> 
> >> >> 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. 
> >> 
> >> Yeah.  It's hard to imagine how "compile-time multimethods" would be
> >> any different from what C++ already provides in terms of overload
> >> resolution and partial ordering.

Round 2. Although the statement itself is fine, in this context it
sounds like an argument against using compile-time in mm. We should
take best of two worlds.
On one hand, if you put all mm function in one big class and apply
metaprogramming you can get rid of class relationship registration. On
the other hand, it's not flexible because, err, all are in one class.
In some cases, this is fine because many people don't like to write
inheritance relation twice unless there is a special reason (Boost.Python
is a good example).

> > There is something more then runtime and compile-time. It's initialization
> > time. Multimethods might be initialized with lots of MPL and other cool
> > compile-time stuff and yet might being used at runtime flexibly.
> 
> Sure, I'm familiar with that technique.  One of my FSM examples uses
> dispatch tables built at initialization time.

Of course, you are!

-- 
Alexander Nasonov