From: Sean O'Halpin <sean.ohalpin@...>
Date: 2006-07-08T10:46:27+09:00
Subject: Re: About 1.9 #__method__ feature.

On 7/7/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
> 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
>
> --
[snipped shameless self-promotion ;)]

OK - I think I get what you're saying now. I'll try to paraphrase (and
please correct me if I get this wrong).

Because in Ruby ~everything~ is an object then ~every~ method
(function, procedure) call is a message sent to an object. Therefore
there is no such thing as a receiverless method, whether or not that
receiver is explicitly specified or implicitly assumed.

So really the distinction is between implicit (unspecified) and
explicit (specified) receiver.

Is that the point you're making? If so, I wholly agree.

By the way, I think you and Ara are saying the same thing but in
different ways. ;)

Regards,
Sean