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