From: ara.t.howard@...
Date: 2006-07-08T02:57:11+09:00
Subject: Re: About 1.9 #__method__ feature.

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

seriously, if you want __two__ mechanisms to determine access control then
that means patching the c code.  if we keep one mechanism - receiverless calls
- matz is done.

so i ask, what __would__ the exact (in c code terms) mechanism for

   obj.send 'meth'

being able to access private methods be??

> 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".

yet i do ;-)

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.


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

cheers.

-a
-- 
suffering increases your inner strength.  also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama