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