From: dblack@...
Date: 2006-07-08T03:22:39+09:00
Subject: Re: About 1.9 #__method__ feature.

Hi --

On Sat, 8 Jul 2006, ara.t.howard@noaa.gov wrote:

> On Sat, 8 Jul 2006 dblack@wobblini.net wrote:
>
>> I don't mean "matter of style" in the sense of "determined by stylistic
>> choice".  Rather, I mean that the whole concept of a "receiverless" method
>> call only has meaning with respect to the actual typography of the 
>> language:
>>
>>   meth       # receiverless (implied receiver [self])
>>   obj.meth   # with receiver (explicit receiver)
>> 
>> In fact, *no* method call is truly "receiverless"; there's always a
>> receiver.  So we're using "receiverless" as shorthand for: typed in the
>> bareword style.
>
> agreed.
>
>> My disagreement with Ara is over whether there's a notion of "a 
>> receiverless
>> method call" in the language, distinct from the question of whether there 
>> is
>> or is not an explicit receiver present.  I think there isn't; I think that
>> in a case like this:
>>
>>  obj.send(:meth)
>> 
>> the whole concept of whether or not there is an explicit receiver at the
>> moment that obj executes meth is meaningless.
>
> but not for ruby - it's presisely this distintion that the language, for
> better or worse, uses to allow private methods to be called.
>
>
>> If obj.send(:meth) can bypass the access-level mechanism and reach private
>> methods, it's not because a receiverless method call has taken place.  It's
>> because send, *like* a receiverless method call, is allowed access to
>> private methods.
>
> but that means there arr two mechanisms for determining access.  that's
> complicated.  why not keep it simple and explain it thusly:
>
>  private means you cannot have a recieve
>
>  funcall means you will not have a receiver

Because that turns "not having a receiver" into a metaphor, instead of
something that's actually manifest in the code.

> i do not distinguish from 'calling methods' and 'sending message'.  indeed, i
> think many from smalltalk or objective-c backgrounds would also not make this
> distiction.

Many from a Ruby background don't either :-)  I don't in casual usage,
but at the level where method names are forged based on what's
happening, I think it plays a key role.  That's why send is send and
not call :-)

> it's interesting how differently we think isn't it!?  ;-)

Indeed :-)


David

-- 
  "To fully realize the potential of Rails, it's crucial that you take
    the time to fully understand Ruby--and with "Ruby for Rails" David
       has provided just what you need to help you achieve that goal."
       -- DAVID HEINEMEIER HANSSON, in the foreword to RUBY FOR RAILS.
  Complete foreword & sample chapters at http://www.manning.com/black!