Re: [boost] Re: MultiMethod/Visitor Interest
_____ From: Danil Shopyrin Sent: Monday, September 27, 2004 11:13 AM To: 'boost@lists.boost.org' Subject: RE: Re: [boost] Re: MultiMethod/Visitor Interest Hi! http://tinyurl.com/5qxky - it's a "preliminary" version of my solution. The [maybe] complete version can be found at http://www.codeproject.com/cpp/mmcppfcs.asp. And some of mentioned drawbacks are already eliminated. 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). There is a big resource of flexibility. By reducing the 'type safety sugar' this solution can be extended. Look on "Compilation in separate modules" section. And so on. I hope that the approach can be extended to met 'practical solution' requirements. But this is a hard job to one person to produce consistent set of these requirements. However, I think that "clear" solution is also practical in many cases. Further, about drawbacks: 1) Compile time. Yes, this solution is strongly compile time. But I think it is an advantage :-) 2) You are right. There is no "next_method". I was never think of them. 3) Intrusive. It is eliminated. 4) "distinguishes the first argument". It is eliminated. 5) Gnarly user code. Look at up-to-date "tiny use case" at http://sdanil.narod.ru/mm/m2vd3_v5.zip -- Danil
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
Jesse Jones <jesjones@mindspring.com> 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. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Jesse Jones <jesjones@mindspring.com> 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.
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. -- Alexander Nasonov
Alexander Nasonov <alnsn@yandex.ru> writes:
David Abrahams wrote:
Jesse Jones <jesjones@mindspring.com> 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.
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. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Alexander Nasonov <alnsn@yandex.ru> writes:
David Abrahams wrote:
Jesse Jones <jesjones@mindspring.com> 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
Alexander Nasonov <alnsn@yandex.ru> writes:
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).
Of what? You never describe an inheritance relation twice in Boost.Python (?) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Alexander Nasonov <alnsn@yandex.ru> writes:
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).
Of what? You never describe an inheritance relation twice in Boost.Python (?)
You describe it in _addition_ to normal inheritance. That's two. -- Alexander Nasonov
Alexander Nasonov <alnsn@yandex.ru> writes:
David Abrahams wrote:
Alexander Nasonov <alnsn@yandex.ru> writes:
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).
Of what? You never describe an inheritance relation twice in Boost.Python (?)
You describe it in _addition_ to normal inheritance. That's two.
Oh, OK. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
Just as a FYI: Lassi A. Tuura posted this proposal regarding multimethods to the GCC list yesterday: <http://gcc.gnu.org/ml/gcc/2004-09/threads.html#01601> Aaron W. LaFramboise
participants (5)
-
Aaron W. LaFramboise -
Alexander Nasonov -
Danil Shopyrin -
David Abrahams -
Jesse Jones