Re: [boost] Re: MultiMethod/Visitor Interest

From: Jesse Jones (jesjones_at_[hidden])
Date: 2004-09-18 14:41:17

On Sep 18, 2004, at 4:15 AM, David Abrahams wrote:

> How does this stack up against http://tinyurl.com/5qxky?
>
Here's a rundown on my impression of Danil's library. (-) are points 
where I think my library is better, (+) where Danil's library is 
better:

- Danil uses type lists to do dispatch. In other words, like most C++ 
multimethod libs, it's a purely compile time solution. This has some 
advantages, but has the major disadvantage that the methods are fixed 
at compile time. This makes it a lot more difficult to use multimethods 
in any sort of reusable framework.

- There's no support for any kind of next_method feature. This is 
really important for some applications (think of event + view 
dispatching for example). Users might be able to manually call the 
appropriate next method, but that seems like a brittle and error-prone 
solution.

- Danil's solution is intrusive: it requires that classes that are 
dispatched upon have an Accept member and members for each operation 
that you want to treat as a multimethod. This is really bad IMO (altho 
not all type list solutions impose this requirement).

- It's a minor point, but Danil syntactically distinguishes the first 
argument. For example, to test if two shapes intersect he uses code 
like this: arg0->Cross(arg1). This is a bit goofy: the whole point of 
multimethods is that none of the arguments are distinguished and that 
operations do not belong to objects (and are therefore readily 
extensible).

- His example has some gnarly template code at the user level. I doubt 
many users are going to want to build type lists by hand using 
compile-time ifs. It's also not going to scale very well past two 
arguments if people have to write that stuff by hand.

+ Danil's code will dispatch faster. Mainly because he moves more logic 
into compile time and doesn't support next_method.

+ All of his code is header level stuff. I have one cpp file.

+ He's able to use compile time tests for subtyping. I have to do this 
at runtime so types that are to be polymorphically dispatched must 
inform the system of their base class(es) using a macro like this: 
DECLARE_SUBTYPE(line_shape, shape);.

+ Symmetric methods are easier with his scheme (eg circle + rect and 
rect + circle can be implemented with one method).

   -- Jesse