Open-Method
1 view
Skip to first unread message
莫华枫
Mar 31, 2008, 2:22:42 AM3/31/08
to TopLanguage
Bjarne在最近的interview里提到他和他的学生一起研究了Multi-Method问题，并且给出了一个面向C++的解决方案。在卓越的google的帮助下，我找到了那篇论文。他们称此方案为"Open-Method"，可以解决诸多现有single dispatch所带来的问题，并且拥有很好的性能。Open-Method不需要visitor pattern带来的繁琐和限制，也没有rtti带来的性能问题。看起来不错。
--
反者道之动，弱者道之用
m...@seaskysh.com
longsh...@gmail.com
http://blog.csdn.net/longshanks/
--
反者道之动，弱者道之用
m...@seaskysh.com
longsh...@gmail.com
http://blog.csdn.net/longshanks/
pongba
Mar 31, 2008, 7:09:20 AM3/31/08
to pon...@googlegroups.com
嗯嗯，当时我还写邮件问了他一个关于这篇Paper的技术问题，以下：
>
> Plus, it enables the client code to say:"Hey, I know I have a
> reference here whose dynamic type I don't, but I JUST want static
> overload OK?!", which is something the original design doesn't support
> (the dynamic dispatch is always performed if the type of an argument
> is indeterminable at compile-time).
The snag that I see is that to get the far most frequently desired
result, you have to say something extra and if you forget you'll in most
cases quietly get the wrong result. I suspect that would be a very nasty
little language design error.
看了BJ的回复，我只能说，姜，还是老的辣。
这种理念，还有Anders设计C#里面的一些理念，是真正的PL practical research的精神，比起关在象牙塔里面捣鼓什么killer&fancy语言特性的来说要更为可贵。
--
刘未鹏(pongba)|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba
pongba wrote:
> Dear, Dr Stroustrup:)
>
> I have a specific question regarding the design rationale of Open
> Multi-Methods for C++.
> The proposed way of making a method dynamically-overloadable is to
> declare each of its parameters virtual:
>
> void foo(virtual X&, virtual Y&);
>
> While this approach seems intuitive w.r.t. the design of virtual
> functions in C++, I think it has a major limitation, that is, it left
> the choice of whether a method is dynamically-overloadable to the
> implementer of that method, rather than the final user.
>
> So, would it be a lot more flexible if we let the user decide whether
> dynamic dispatch is performed, such as:
>
> void foo(X&, Y&);
> void foo(X&, Z&);
>
> X& x = ...;
> Y& y = ...;
> foo(virtual x, virtual y); // or virtual foo(x, y);
>
> This approach has another advantage - it transparently makes existing
> code dynamically-overloadable.
but is that an advantage?> Dear, Dr Stroustrup:)
>
> I have a specific question regarding the design rationale of Open
> Multi-Methods for C++.
> The proposed way of making a method dynamically-overloadable is to
> declare each of its parameters virtual:
>
> void foo(virtual X&, virtual Y&);
>
> While this approach seems intuitive w.r.t. the design of virtual
> functions in C++, I think it has a major limitation, that is, it left
> the choice of whether a method is dynamically-overloadable to the
> implementer of that method, rather than the final user.
>
> So, would it be a lot more flexible if we let the user decide whether
> dynamic dispatch is performed, such as:
>
> void foo(X&, Y&);
> void foo(X&, Z&);
>
> X& x = ...;
> Y& y = ...;
> foo(virtual x, virtual y); // or virtual foo(x, y);
>
> This approach has another advantage - it transparently makes existing
> code dynamically-overloadable.
>
> Plus, it enables the client code to say:"Hey, I know I have a
> reference here whose dynamic type I don't, but I JUST want static
> overload OK?!", which is something the original design doesn't support
> (the dynamic dispatch is always performed if the type of an argument
> is indeterminable at compile-time).
result, you have to say something extra and if you forget you'll in most
cases quietly get the wrong result. I suspect that would be a very nasty
little language design error.
看了BJ的回复，我只能说，姜，还是老的辣。
这种理念，还有Anders设计C#里面的一些理念，是真正的PL practical research的精神，比起关在象牙塔里面捣鼓什么killer&fancy语言特性的来说要更为可贵。
2008/3/31 莫华枫 <longsh...@gmail.com>:
--
刘未鹏(pongba)|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba
莫华枫
Mar 31, 2008, 9:34:14 AM3/31/08
to pon...@googlegroups.com
看了BJ的回复，我只能说，姜，还是老的辣。
这种理念，还有Anders设计C#里面的一些理念，是真正的PL practical research的精神，比起关在象牙塔里面捣鼓什么killer&fancy语言特性的来说要更为可贵。
那是自然的啦，人吃过的盐，比咱走过的路还多嘛。:P
open-method有两点让我感兴趣：
1、文章提到一个参数的open-method实际上等价于虚函数带来的single dispatch。重要的是open-method是非侵入的。这又提供了一个更灵活的runtime bound手段。
2、如果在open-method中用runtime concept代替base class，又会怎样呢？:)
open-method有两点让我感兴趣：
1、文章提到一个参数的open-method实际上等价于虚函数带来的single dispatch。重要的是open-method是非侵入的。这又提供了一个更灵活的runtime bound手段。
2、如果在open-method中用runtime concept代替base class，又会怎样呢？:)
2008/3/31 莫华枫 <longsh...@gmail.com>:
Bjarne在最近的interview里提到他和他的学生一起研究了Multi-Method问题，并且给出了一个面向C++的解决方案。在卓越的google的帮助下，我找到了那篇论文。他们称此方案为"Open-Method"，可以解决诸多现有single dispatch所带来的问题，并且拥有很好的性能。Open-Method不需要visitor pattern带来的繁琐和限制，也没有rtti带来的性能问题。看起来不错。
--
反者道之动，弱者道之用
m...@seaskysh.com
longsh...@gmail.com
http://blog.csdn.net/longshanks/
--
刘未鹏(pongba)|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba
piboye.liu
Mar 31, 2008, 9:23:49 PM3/31/08
to pon...@googlegroups.com
如果Open_Method可以出现在下个标准中，是不是意味着OOP就要过时了
2008-04-01
piboye.liu
发件人： pongba
发送时间： 2008-03-31 19:09:41
抄送：
主题： [TopLanguage] Re:
Open-Method
pongba
Apr 1, 2008, 1:03:41 AM4/1/08
to pon...@googlegroups.com
有点那个意味，但我认为class提供的封装能力还是会需要用到的。
如果open method有了，C++里面的"一组紧凑的core functions+任意多的free functions"这种best practice就可以更不受约束了，因为这下连虚函数都能是free function了。
如果open method有了，C++里面的"一组紧凑的core functions+任意多的free functions"这种best practice就可以更不受约束了，因为这下连虚函数都能是free function了。
2008/4/1 piboye.liu <piboy...@gmail.com>:
piboye.liu
Apr 1, 2008, 1:25:45 AM4/1/08
to pon...@googlegroups.com
去年的时候我自己也实现了个visitor模式的方法，自己叫它multi_function,
因为它只能对一个参数类型来进行运行时分派，但比visitor模式的OO实现更灵活很多。
好像现在都比较流行用boost的function 对象来取代以前的virtual
function设计。
2008-04-01
piboye.liu
发件人： pongba
发送时间： 2008-04-01 13:04:08
莫华枫
Apr 1, 2008, 1:34:48 AM4/1/08
to pon...@googlegroups.com
2008/4/1 pongba <pon...@gmail.com>:
有点那个意味，但我认为class提供的封装能力还是会需要用到的。
如果open method有了，C++里面的"一组紧凑的core functions+任意多的free functions"这种best practice就可以更不受约束了，因为这下连虚函数都能是free function了。
呵呵，单片式设计的最后一个借口也都没有了。:)
Reply all
Reply to author
Forward
0 new messages