Re: method names in 1.9

Hi --

On Mon, 12 Nov 2007, Austin Ziegler wrote:

> On 11/11/07, Charles Oliver Nutter <[e-mail]> wrote:
>> David Flanagan wrote:
>>> IIRC, the reason for a visiblity-honoring method is so that if your
>>> intent is to invoke a (public) method that is part of a published API
>>> you won't inadvertently invoke a (private) implementation-dependent
>>> helper method with the same name defined by a subclass.  You fail fast
>>> with an exception rather than getting unexpected behavior that comes
>>> from calling the wrong method.
>> I thought it might be something like that. For that purpose,
>> invoke_method seems reasonable, since it does say to me "please invoke
>> this method as though I were calling it", and I'd expect the same rules
>> to apply.
>
> Why not #call_method then?
>
> It inverts the #method().call() mechanism, and is a bit clearer,
> perhaps. (Interesting, at least in 1.8.6 #method(:bar).call will call
> a private method.)

It sort of inverts it, except that it's one level away:

   a_method.bind(obj).call
   obj.call_method(string_or_symbol)

In other words, if I were writing a method called #call_method (or
#invoke_method), it would be:

   obj.call_method(a_method)

Somewhere in the inversion, though, we go from a method object to a
string.


David

-- 
Upcoming training by David A. Black/Ruby Power and Light, LLC:
   * Advancing With Rails, Berlin, Germany, November 19-22
   * Intro to Rails, London, UK, December 3-6 (by Skills Matter)
See http://www.rubypal.com for details!