About 1.9 #__method__ feature

[Yukihiro_Matsumoto2 (Yukihiro Matsumoto)]

Hi,

But we already have module_function, which has never been complained
for more than 10 years. I think it's OK to meet small confusion for
the first timers, if we can use the name with right mnemonic for the
functionality. Probably the reason behind the funcall is my Lisp
background.

I'm not a first timer though, and I find it confusing You're
right about module_function, but it also (in my experience) doesn't
get used much.

I think you're still a first timer to the term "funcall" in Ruby.
Anyway, my point is whether funcall etc. would work as good mnemonic
or not, _after_ users get used to them.

The functionality we're talking about, as I understand it, is: send a
message to an object, with the stipulation that the object treat the
message indifferently with respect to the access level of the method
(if any) that corresponds to the message.

Right, if I understand the work stipulation correctly.

To me, that leads to things like send! or absolute_send or inner_send
or instance_send (which I think Sean O'Halpin just suggested). It's
still basically a "send" operation.

The part I don't understand is why the inclusion of private methods
suddenly makes it something other than a "send" -- why it requires a
(basically) new concept, the concept of objects having "functions" and
responding directly to "call" requests.

"send" and "funcall" are both taken from lisp function names; "send"
invokes a method; "funcall" invokes a function. In Ruby, "send"
invokes a method; "funcall" invokes a method in functional style.
They are short names for mnemonic. There should be official, longer
orthogonal, and exact names for the functionality. I proposed
"invoke_method" and "invoke_functional_method", but they are not final
decision.

              matz.

···

In message "Re: About 1.9 #__method__ feature." on Fri, 7 Jul 2006 21:30:03 +0900, dblack@wobblini.net writes:

[7rans]

Sean O'Halpin wrote:

How about instance_send (on analogy with instance_eval and instance_exec)?

+1

Why make this more complex than it needs to be? #instance_send is
reasonably obvious, #fucncall is not at all and is only menaingful to
lispers and brings in a whole new set of concepts about "functional
style".

T.

[David_A_Black3 (David A. Black)]

Hi --

Hi,

>> But we already have module_function, which has never been complained
>> for more than 10 years. I think it's OK to meet small confusion for
>> the first timers, if we can use the name with right mnemonic for the
>> functionality. Probably the reason behind the funcall is my Lisp
>> background.
>
>I'm not a first timer though, and I find it confusing You're
>right about module_function, but it also (in my experience) doesn't
>get used much.

I think you're still a first timer to the term "funcall" in Ruby.
Anyway, my point is whether funcall etc. would work as good mnemonic
or not, _after_ users get used to them.

>The functionality we're talking about, as I understand it, is: send a
>message to an object, with the stipulation that the object treat the
>message indifferently with respect to the access level of the method
>(if any) that corresponds to the message.

Right, if I understand the work stipulation correctly.

Basically a condition imposed.

>To me, that leads to things like send! or absolute_send or inner_send
>or instance_send (which I think Sean O'Halpin just suggested). It's
>still basically a "send" operation.
>
>The part I don't understand is why the inclusion of private methods
>suddenly makes it something other than a "send" -- why it requires a
>(basically) new concept, the concept of objects having "functions" and
>responding directly to "call" requests.

"send" and "funcall" are both taken from lisp function names; "send"
invokes a method; "funcall" invokes a function. In Ruby, "send"
invokes a method; "funcall" invokes a method in functional style.

Then it's not really taken from Lisp

They are short names for mnemonic. There should be official, longer
orthogonal, and exact names for the functionality. I proposed
"invoke_method" and "invoke_functional_method", but they are not final
decision.

I'm probably going in circles, but I'm not seeing a functional-style
method call here:

    obj.funcall(:meth)

funcall itself isn't being called functionally, and meth isn't being
called at all -- that is, you don't see this in the program:

    meth

and therefore it's impossible, I think, to talk about the "style" of
the "method invocation".

If I'm not convincing you, maybe I can suggest:

   invoke_method_functionally

instead of invoke_functional_method. I honestly don't think either of
them is perfect, but it would be probably be better not to introduce
the separate notion of a "functional method", since the *same* method
can be invoked in different ways.

David

···

On Fri, 7 Jul 2006, Yukihiro Matsumoto wrote:

In message "Re: About 1.9 #__method__ feature." > on Fri, 7 Jul 2006 21:30:03 +0900, dblack@wobblini.net writes:

--
  "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\!

[Ara.T.Howard6 (Ara.T.Howard)]

consider:

   harp:~ > cat a.rb
   class Object
     def funcall(*a, &b) instance_eval{ send *a, &b } end
     alias_method 'instance_send', 'funcall'
   end

   module A
   private
     def A.m() p 42 end
   end

   module B
   private
     def B.m() p 'forty-two' end
   end

   A.funcall 'm'
   B.funcall 'm'

   A.instance_send 'm'
   B.instance_send 'm'

   harp:~ > ruby a.rb
   42
   "forty-two"
   42
   "forty-two"

with funcall we can consider modules as namespaces, each of which defines an
'm' method and in whose context 'm' can be called. if you've been coding ruby
for a while you can probably easily read over the

   A.instance_send 'm'
   B.instance_send 'm'

lines. but to newbies, or even non-newbies, the

   'modules are instances of a Module class which is a Class which is a Module
   which are both Objects'

circular thinking makes it slightly less than intuitive as to the reason one
can call 'instance' methods on modules or classes.

the receiveless context sensitive paradigm, although a new concept, is
orthoganal to public/private and instance/class/module and can be expained
rather simply: if one does

   obj.funcall :meth, 42

it's __always__ like being 'inside' the object, which means in an instance
method for instances and insides a class definition for classes, etc, and
doing

   meth, 42

2 cts.

-a

···

On Fri, 7 Jul 2006 transfire@gmail.com wrote:

Sean O'Halpin wrote:

How about instance_send (on analogy with instance_eval and instance_exec)?

+1

Why make this more complex than it needs to be? #instance_send is
reasonably obvious, #fucncall is not at all and is only menaingful to
lispers and brings in a whole new set of concepts about "functional
style".

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

[Juergen_Strobel]

+2

I would like #send! too, or similiar variations. I don't like #funcall
because even with lispers it may lead to wrong associations. Sure
people will get used to it, but why confound them in the first place?

And as mentioned elsewhere often enough, no method call (or message
sent) is really receiverless, it just may be without an explicit
receiver.

-Jürgen

···

On Fri, Jul 07, 2006 at 11:58:34PM +0900, transfire@gmail.com wrote:

Sean O'Halpin wrote:

> How about instance_send (on analogy with instance_eval and instance_exec)?

+1

Why make this more complex than it needs to be? #instance_send is
reasonably obvious, #fucncall is not at all and is only menaingful to
lispers and brings in a whole new set of concepts about "functional
style".

T.

--
The box said it requires Windows 95 or better so I installed Linux

[Yukihiro_Matsumoto2 (Yukihiro Matsumoto)]

Hi,

"send" and "funcall" are both taken from lisp function names; "send"
invokes a method; "funcall" invokes a function. In Ruby, "send"
invokes a method; "funcall" invokes a method in functional style.

Then it's not really taken from Lisp

OK, it's inspired by Lisp functions.

I'm probably going in circles, but I'm not seeing a functional-style
method call here:

   obj.funcall(:meth)

funcall itself isn't being called functionally, and meth isn't being
called at all -- that is, you don't see this in the program:

   meth

and therefore it's impossible, I think, to talk about the "style" of
the "method invocation".

Hmm, I think I understand your point. Let me think about it.

If I'm not convincing you, maybe I can suggest:

  invoke_method_functionally

I agree this is better than invoke_functional_method. I am still
looking for the better name.

instead of invoke_functional_method. I honestly don't think either of
them is perfect, but it would be probably be better not to introduce
the separate notion of a "functional method", since the *same* method
can be invoked in different ways.

Point taken (about invoke_method_functionally).

              matz.

···

In message "Re: About 1.9 #__method__ feature." on Fri, 7 Jul 2006 22:49:11 +0900, dblack@wobblini.net writes:

[Ara.T.Howard6 (Ara.T.Howard)]

I'm probably going in circles, but I'm not seeing a functional-style
method call here:

  obj.funcall(:meth)

yet one is implied. just as

   attr 'a'

doesn't show a meta-programming-style method. one can imagine it's syntax,
yet meta-programming is done.

nothing in ruby can be purely functional. even if you write everything as in

   this = lambda {
     that = lambda {
     }
   }

you can turn around and do

   this.inspect # oops, object call

nonetheless

   obj.funcall :meth

says to turn the call into a recieverless message, one in which self is
implied, and thus it looks like a functional call bound in the context of self
so private calls can be made.

i think it's fair to say the closest one can come to 'functional' style in
ruby is to use recieveless messages, eg

   def foo() bar end
   def bar() 42 end

   bar # pretend functional. really it's self.bar of course

it just so happens that this is also the requirement to call private methods
in ruby so a public interface to accomplish receiverless messages effectively
gets inside the object and becomes a private 'send'.

i finally decided that i like funcall because i realized it's not __only__ an

   instance_eval{ send msg }

but is simply a generic way of doing receiverless calls. there are other
possible uses for this technique and so a more generic name than
'instance_send', etc. is appropriate.

that's not to say an alias shouldn't exist, however. why not funcall and

   alias_method 'send!', 'funcall'

or

   alias_method 'instance_send', 'funcall'

matz?

funcall itself isn't being called functionally

indeed. it's calling 'meth' functionally.

, and meth isn't being called at all -- that is, you don't see this in the
program:

  meth

that's a bit weak. as programmers i think we can all agree that tons of
methods get 'called' even though we don't see them. that's the very idea
behind abstraction after all - you don't think people don't realize that

   belongs_to ...

actually 'calls a bunch of stuff' do you? anyhow, i think that even a below
average ruby coder has no issue understanding that some methods call many
others behind the scenes.

and therefore it's impossible, I think, to talk about the "style" of the
"method invocation".

but it's only one layer of abstraction deep? we could easily reason to
ourselves, while coding, that we needed a way to call private methods and
start using

   obj.instance_eval{ send msg }

after we did this three or four times we could abstract it into

   funcall = lambda{|obj, msg, *a| obj.instance_eval{ send msg, *a }}

and away we'd go

   funcall[ list, :push, 42 ]

now it's two layers of code reading to say that the style of method invocation
is receiverless and that's it's preciesly that feature, that of having a
receiver, that makes a method call 'object oriented'. note that's it's also
not a purely procedure call because

   send msg, *a

has the notion of context as in

   let self = me in
     send msg, *a;;

and it's this context, combined with the lack of an explicit receiver that
gives a functional flavour.

regards.

-a

···

On Fri, 7 Jul 2006 dblack@wobblini.net wrote:
--
suffering increases your inner strength. also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama

[Austin_Ziegler5 (Austin Ziegler)]

This is for an implicit-receiver mechanism, right? Why not:

  invoke_method # send in 1.9
  invoke_implicit_method # funcall in 1.9

OR:

  invoke_method_implicitly # funcall

OR:

  invoke_method_with_implicit_receiver

The last is a joke. Mostly.

-austin

···

On 7/7/06, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

>If I'm not convincing you, maybe I can suggest:
>
> invoke_method_functionally

I agree this is better than invoke_functional_method. I am still
looking for the better name.

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

[Logan_Capaldo]

Steal another name from lisp?

obj.apply(:meth, 1, 2, 3)

It's not send, but it's not funcall either.

obj apply your :meth function to the arguments 1,2,3

Just throwing stuff out there, feel free to ignore me

···

On Jul 7, 2006, at 10:23 AM, Yukihiro Matsumoto wrote:

Hi,

In message "Re: About 1.9 #__method__ feature." > on Fri, 7 Jul 2006 22:49:11 +0900, dblack@wobblini.net writes:

>> "send" and "funcall" are both taken from lisp function names; "send"
>> invokes a method; "funcall" invokes a function. In Ruby, "send"
>> invokes a method; "funcall" invokes a method in functional style.
>
>Then it's not really taken from Lisp

OK, it's inspired by Lisp functions.

>I'm probably going in circles, but I'm not seeing a functional-style
>method call here:
>
> obj.funcall(:meth)
>
>funcall itself isn't being called functionally, and meth isn't being
>called at all -- that is, you don't see this in the program:
>
> meth
>
>and therefore it's impossible, I think, to talk about the "style" of
>the "method invocation".

Hmm, I think I understand your point. Let me think about it.

>If I'm not convincing you, maybe I can suggest:
>
> invoke_method_functionally

I agree this is better than invoke_functional_method. I am still
looking for the better name.

>instead of invoke_functional_method. I honestly don't think either of
>them is perfect, but it would be probably be better not to introduce
>the separate notion of a "functional method", since the *same* method
>can be invoked in different ways.

Point taken (about invoke_method_functionally).

              matz.

[David_A_Black3 (David A. Black)]

Hi --

i think it's fair to say the closest one can come to 'functional' style in
ruby is to use recieveless messages, eg

def foo() bar end
def bar() 42 end

bar # pretend functional. really it's self.bar of course

Yes and no. It has the effect as self.bar, but it actually *is* this:

   bar

namely, a bare word, on the screen (or in a file, or whatever) with no
explicit receiver.

it just so happens that this is also the requirement to call private methods
in ruby so a public interface to accomplish receiverless messages effectively
gets inside the object and becomes a private 'send'.

i finally decided that i like funcall because i realized it's not __only__ an

instance_eval{ send msg }

but is simply a generic way of doing receiverless calls. there are other
possible uses for this technique and so a more generic name than
'instance_send', etc. is appropriate.

I disagree. I don't think there's such a thing as a "receiverless
call", outside of what's actually visible to the eye. I don't see any
advantage to stretching the term to mean something other than "a
method call without an explicit receiver". It's not even clear what
it would mean.

matz?

funcall itself isn't being called functionally

indeed. it's calling 'meth' functionally.

I'd say it's sending the method "meth" to an object symbolically. I
don't don't see this as a functional-style call of "meth". A
functional-style call of meth would look like this:

   meth

, and meth isn't being called at all -- that is, you don't see this in the
program:

  meth

that's a bit weak. as programmers i think we can all agree that tons of
methods get 'called' even though we don't see them. that's the very idea
behind abstraction after all - you don't think people don't realize that

belongs_to ...

actually 'calls a bunch of stuff' do you? anyhow, i think that even a below
average ruby coder has no issue understanding that some methods call many
others behind the scenes.

But that's the whole issue: how what's visible relates to what's
behind the scenes. I like to keep the layers separate, not because we
don't know that eventually "meth" gets called, but because
understanding it sequentially makes more sense of more cases.

This:

   obj.send(:meth)

is, I think, best understood as "sending the message 'meth'
symbolically to obj". If you call it "calling the method 'meth'",
then you have to back-pedal to deal with things like method_missing,
private methods, and so on.

Yes, it's convenient to talk about "calling meth on obj" when you do:

   obj.meth

But it's not entirely accurate, and once the layers are splayed out
with symbolic references to method names, I think it becomes quite
important not to collapse message-sending and method-calling.

Again, I'd rather just have simple names for what's actually there,
rather than decide up front that it has to be called something else
and then decide what the best alternative name is.

and therefore it's impossible, I think, to talk about the "style" of the
"method invocation".

but it's only one layer of abstraction deep? we could easily reason to
ourselves, while coding, that we needed a way to call private methods and
start using

obj.instance_eval{ send msg }

after we did this three or four times we could abstract it into

funcall = lambda{|obj, msg, *a| obj.instance_eval{ send msg, *a }}

and away we'd go

funcall[ list, :push, 42 ]

now it's two layers of code reading to say that the style of method invocation
is receiverless and that's it's preciesly that feature, that of having a
receiver, that makes a method call 'object oriented'. note that's it's also
not a purely procedure call because

send msg, *a

has the notion of context as in

let self = me in
   send msg, *a;;

and it's this context, combined with the lack of an explicit receiver that
gives a functional flavour.

But I don't want to go through two layers when I use a term like
"receiverless". I want it to mean "without an explicit receiver", not
"equivalent to what *would* be without an explicit receiver if it were
being used in a way that required a decision as to the inclusion or
exclusion of a receiver...."

I would say that when you do:

   obj.send(:meth)

the "receiver/receiverless" status of the execution of the method
"meth" is undefined. There's no opportunity for there to be or not be
a receiver; it's not that kind of operation.

David

···

On Fri, 7 Jul 2006, ara.t.howard@noaa.gov wrote:

--
  "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\!

[Ara.T.Howard6 (Ara.T.Howard)]

i was just about to suggest that name. still, there is nothing which implies
are receiverless context sensitive call that can access private methods with
that name is there? (see my post to david). nonetheless i like this name.

cheers.

-a

···

On Fri, 7 Jul 2006, Logan Capaldo wrote:

Steal another name from lisp?

obj.apply(:meth, 1, 2, 3)

It's not send, but it's not funcall either.

obj apply your :meth function to the arguments 1,2,3

Just throwing stuff out there, feel free to ignore me

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

[David_A_Black3 (David A. Black)]

Hi --

···

On Fri, 7 Jul 2006, ara.t.howard@noaa.gov wrote:

On Fri, 7 Jul 2006, Logan Capaldo wrote:

Steal another name from lisp?

obj.apply(:meth, 1, 2, 3)

It's not send, but it's not funcall either.

obj apply your :meth function to the arguments 1,2,3

Just throwing stuff out there, feel free to ignore me

i was just about to suggest that name. still, there is nothing which implies
are receiverless context sensitive call that can access private methods with
that name is there?

No -- which is why I like it much more than 'funcall' and such It
doesn't introduce the criterion of "receiverlessness" into a situation
where the concept of having or not having a receiver isn't relevant.

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\!

[David_A_Black3 (David A. Black)]

Hi --

Hi --

Steal another name from lisp?

obj.apply(:meth, 1, 2, 3)

It's not send, but it's not funcall either.

obj apply your :meth function to the arguments 1,2,3

Just throwing stuff out there, feel free to ignore me

i was just about to suggest that name. still, there is nothing which implies
are receiverless context sensitive call that can access private methods with
that name is there?

No -- which is why I like it much more than 'funcall' and such It
doesn't introduce the criterion of "receiverlessness" into a situation
where the concept of having or not having a receiver isn't relevant.

Just to follow up and clarify:

I'm not saying I think the method name shouldn't express the fact that
it can call private methods. That's why I've been advocating "send!"
(the "dangerous" version of send). 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

···

On Sat, 8 Jul 2006, dblack@wobblini.net wrote:

On Fri, 7 Jul 2006, ara.t.howard@noaa.gov wrote:

On Fri, 7 Jul 2006, Logan Capaldo wrote:

--
  "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\!

[Sean_O_Halpin]

FWIW, I'm already using apply, i.e.:

module Enumerable
  def apply(&block)
    map {|i| i.instance_eval(&block) }
  end
end

which seems more in keeping with its meaning in lisp (though not
really the same).

Regards,
Sean

···

On 7/7/06, dblack@wobblini.net <dblack@wobblini.net> wrote:

Hi --

On Fri, 7 Jul 2006, ara.t.howard@noaa.gov wrote:

> On Fri, 7 Jul 2006, Logan Capaldo wrote:
>
>> Steal another name from lisp?
>>
>> obj.apply(:meth, 1, 2, 3)
>>
>> It's not send, but it's not funcall either.
>>
>> obj apply your :meth function to the arguments 1,2,3
>>
>> Just throwing stuff out there, feel free to ignore me
>
> i was just about to suggest that name. still, there is nothing which implies
> are receiverless context sensitive call that can access private methods with
> that name is there?

No -- which is why I like it much more than 'funcall' and such It
doesn't introduce the criterion of "receiverlessness" into a situation
where the concept of having or not having a receiver isn't relevant.

David

[Sean_O_Halpin]

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

Regards,
Sean

···

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

[Logan_Capaldo]

I disagree, yours is not especially closer to the Lisp meaning of apply. The only difference (AFAIK) between Lisp's funcall and Lisp's apply is how the argument list is expressed:

[1]> (funcall #'+ 1 2)
3
[2]> (apply #'+ '(1 2))
3

Of course this probably means we should have #funcall and #apply <g>

obj.funcall(:meth, 1, 2)
obj.apply(:meth, [1, 2])

···

On Jul 7, 2006, at 12:43 PM, Sean O'Halpin wrote:

On 7/7/06, dblack@wobblini.net <dblack@wobblini.net> wrote:

Hi --

On Fri, 7 Jul 2006, ara.t.howard@noaa.gov wrote:

> On Fri, 7 Jul 2006, Logan Capaldo wrote:
>
>> Steal another name from lisp?
>>
>> obj.apply(:meth, 1, 2, 3)
>>
>> It's not send, but it's not funcall either.
>>
>> obj apply your :meth function to the arguments 1,2,3
>>
>> Just throwing stuff out there, feel free to ignore me
>
> i was just about to suggest that name. still, there is nothing which implies
> are receiverless context sensitive call that can access private methods with
> that name is there?

No -- which is why I like it much more than 'funcall' and such It
doesn't introduce the criterion of "receiverlessness" into a situation
where the concept of having or not having a receiver isn't relevant.

David

FWIW, I'm already using apply, i.e.:

module Enumerable
def apply(&block)
   map {|i| i.instance_eval(&block) }
end
end

which seems more in keeping with its meaning in lisp (though not
really the same).

Regards,
Sean

[David_A_Black3 (David A. Black)]

Hi --

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

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

···

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

On 7/7/06, dblack@wobblini.net <dblack@wobblini.net> wrote:

--
  "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\!

[Sean_O_Halpin]

Don't forget lisp is receiverless AFAIK apply is usually used to
apply a lambda with arguments to a list. So I think of apply as being
more like:

module Enumerable
  def apply(*args, &block)
    map{|x| x.instance_exec(*args, &block)}
  end
end

But that's only my interpretation.

Regards,
Sean

···

On 7/8/06, Logan Capaldo <logancapaldo@gmail.com> wrote:

On Jul 7, 2006, at 12:43 PM, Sean O'Halpin wrote:

> On 7/7/06, dblack@wobblini.net <dblack@wobblini.net> wrote:
>> Hi --
>>
>> On Fri, 7 Jul 2006, ara.t.howard@noaa.gov wrote:
>>
>> > On Fri, 7 Jul 2006, Logan Capaldo wrote:
>> >
>> >> Steal another name from lisp?
>> >>
>> >> obj.apply(:meth, 1, 2, 3)
>> >>
>> >> It's not send, but it's not funcall either.
>> >>
>> >> obj apply your :meth function to the arguments 1,2,3
>> >>
>> >> Just throwing stuff out there, feel free to ignore me
>> >
>> > i was just about to suggest that name. still, there is nothing
>> which implies
>> > are receiverless context sensitive call that can access private
>> methods with
>> > that name is there?
>>
>> No -- which is why I like it much more than 'funcall' and
>> such It
>> doesn't introduce the criterion of "receiverlessness" into a
>> situation
>> where the concept of having or not having a receiver isn't relevant.
>>
>> David
>>
>
> FWIW, I'm already using apply, i.e.:
>
> module Enumerable
> def apply(&block)
> map {|i| i.instance_eval(&block) }
> end
> end
>
> which seems more in keeping with its meaning in lisp (though not
> really the same).
>
> Regards,
> Sean
>

I disagree, yours is not especially closer to the Lisp meaning of
apply. The only difference (AFAIK) between Lisp's funcall and Lisp's
apply is how the argument list is expressed:

[1]> (funcall #'+ 1 2)
3
[2]> (apply #'+ '(1 2))
3

Of course this probably means we should have #funcall and #apply <g>

obj.funcall(:meth, 1, 2)
obj.apply(:meth, [1, 2])

[Ara.T.Howard6 (Ara.T.Howard)]

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

···

On Sat, 8 Jul 2006 dblack@wobblini.net wrote:
--
suffering increases your inner strength. also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama

[David_A_Black3 (David A. Black)]

Hi --

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

···

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

On Sat, 8 Jul 2006 dblack@wobblini.net wrote:

--
  "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\!