Re: new method dispatch rule (matz' proposal)

Hi,

In message "Re: new method dispatch rule (matz' proposal)"
    on Wed, 24 Jan 2007 10:05:23 +0900, Evan Phoenix <[e-mail]> writes:

|I wanted to chime in with my feelings on this. I personally dislike  
|it. Heres why:
|
|1) Because of the current semantics, most ruby programmers treat  
|self.foo the same as foo(). I'm very wary of making functional style  
|behave much differently than normal method call style. It adds  
|another layer and complexity and strangeness that I believe we do not  
|need nor want. In fact, I think that it's a bug that private methods  
|can only be called using functional style. The method dispatch  
|mechanism can easily detect that the receiver of the method is the  
|same all the current self end look for private methods.

The point is that, as Ruby grows, the requirement for managing name
conflict is raising.  I think we need something that can safely used
to define utility _functions_, without affecting public method set,
nor worrying about name conflict.  But the current "private" nor one
you've described above cannot address this issue.

|2) As an implementor, I loath to think about having to have multiple  
|dispatch paths that must be searched. We're already fighting with the  
|outside world about the perceived slowness of ruby. Adding a new  
|dispatch path that must be considered for EVERY functional style  
|method call will only make things that much slower. Sure there are  
|ways that we implementors can cache things to improve the situation,  
|but I'd rather not have to if we can avoid it.

I understand this one.  I am an implementer too.  ;-)
Since last March, MRI has experimental visibility named 'local' that
works similar to the new private behavior, but I haven't noticed any
performance problem.  By method cache, two hierarchy search cost
nothing.  I admit implementation complexity is the problem.

|I worry that this new, perceived strangeness to users will mean that  
|private will be used even less often then it's used now. And from  
|what I've seen, it's very rarely used now.

Really?  I use it often.

|Which brings up a good question.. whats protected for now?

The protected methods can only be called from methods where receivers
(both callee and caller) belongs to same class (to be more precise,
they should be subclasses of the owner class of the protected method).
I am not excited about this feature.  But this is another story.

							matz.