[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: About 1.9 #__method__ feature.

Logan Capaldo

7/7/2006 2:47:00 PM


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

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 :)
12 Answers

Ara.T.Howard

7/7/2006 2:51:00 PM

0

dblack

7/7/2006 4:32:00 PM

0

dblack

7/7/2006 4:37:00 PM

0

Sean O'Halpin

7/7/2006 4:44:00 PM

0

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

Sean O'Halpin

7/7/2006 4:53:00 PM

0

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

Regards,
Sean

dblack

7/7/2006 5:33:00 PM

0

Ara.T.Howard

7/7/2006 5:57:00 PM

0

dblack

7/7/2006 6:23:00 PM

0

Sean O'Halpin

7/8/2006 1:46:00 AM

0

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

dblack

7/8/2006 2:49:00 AM

0