From: dblack@...
Date: 2006-07-08T02:33:13+09:00
Subject: Re: About 1.9 #__method__ feature.

Hi --

On Sat, 8 Jul 2006, Sean O'Halpin wrote:

> On 7/7/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
>> I just think that
>> "receiverlessness" is a matter of concrete, visible coding style, and
>> not a language-level concept that has any meaning apart from how
>> method calls are actually expressed.
>> 
>> 
>> David
>> 
> Hi David,
>
> I'm not sure I follow you here. Doesn't the following show that it's
> not just a matter of coding style?
>
> class Foo
> def hi
>   puts "hi"
> end
> private :hi
> def foo
>   hi
> end
> def bar
>   self.hi # will fail
> end
> end
>
> f = Foo.new
> f.foo
> f.bar
> #=>private method `hi' called for #<Foo:0x2868198> (NoMethodError)
> #f.hi would also fail as expected

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.

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.

That's why I don't accept the conclusion that obj.send(:meth)
represents a "functional-style" method call -- that is, a bareword
method call.  Rather, I believe that what's happening is that a
message is being sent to an object, symbolically (i.e., at one
symbolic level of remove from the obj.meth mechanism).

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.

Similarly, when I do this:

class C
   def b
   end
   private :b

   def a
     b
   end
end

C.new.a

I do not say, "I have called 'send' on a C object and send it the
symbol :b".  In other words, there can be multiple paths to get to a
private method.

So 'funcall', intended to mean 'called in a functional (receiverless)
manner, makes no sense to me.

Does that help?


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!