Re: new method dispatch rule (matz' proposal)

On Jan 23, 2007, at 10:25 PM, Yukihiro Matsumoto wrote:

> Hi,
>
> In message "Re: new method dispatch rule (matz' proposal)"
>     on Wed, 24 Jan 2007 14:02:16 +0900, Daniel DeLorme <dan- 
> [e-mail]> writes:
>
> |Then I have one last question:
> |
> |  class MessageQueue
> |    def msg; @queue.first; end
> |    def wait; while msg.nil?;end; end
> |  end
> |  module Kernel
> |    private
> |    def msg(x); warn x; end
> |  end
> |
> |In this case, I believe MessageQueue#wait will invoke the Kernel#msg
> |utility "function" (because private methods are looked up first)  
> rather
> |than the intended MessageQueue#msg. Doesn't that defeat the goal  
> stated
> |above?
>
> This is very rare case that
>
>   * the target class override the private method by public method
>   * and there's a functional call of that method
>
> I think it should be warned, or maybe cause error.

Ok, but where to you warn about it? If the answer is at runtime, then  
again, I worry about making dispatch slower as it now has to perform  
extra checks to detect this condition.

But... if the answer is statically, ie, when 'def msg' is run and  
Kernel#msg already exists, then I think that there are more static  
checks that we could do to help the programmer with private methods.  
I'd be happy to talk about them, but I won't waste my breath if  
you're against doing static checks.

I love ruby to death, but I do believe that we could help the  
programmer write better code and make better decisions with some  
static analysis of class hierarchies.

  - Evan

>
> 							matz.
>