Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Little Things

Reply
Thread Tools

Little Things

 
 
dblack@wobblini.net
Guest
Posts: n/a
 
      12-31-2006
Hi --

On Sun, 31 Dec 2006, Daniel Schierbeck wrote:

> I agree that `funcall' is a weird name... "call a function". What
> function? I thought we agreed on calling them methods!


I think the idea is that calling methods without a receiver can be
considered "functional style"; therefore, "funcall", rather than
"send", should be understood to include private methods.

I'm not sure I find it very convincing. I think of the no-receiver
thing as a way of un-cluttering the code a bit, not a departure from
object orientation. After all, there *is* a receiver, and it is
receiving a message.

Also, funcall itself does involve a receiver. So the situation is
that you see this:

obj.funcall(:meth)

and you infer that it includes private methods because *if* you were
calling meth as a private method, there would be no receiver. To me
that involves too much "What if?"


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

 
Reply With Quote
 
 
 
 
Suraj Kurapati
Guest
Posts: n/a
 
      12-31-2006
unknown wrote:
> On Sun, 31 Dec 2006, Daniel Schierbeck wrote:
>
>> I agree that `funcall' is a weird name... "call a function". What
>> function? I thought we agreed on calling them methods!

>
> I think the idea is that calling methods without a receiver can be
> considered "functional style"; therefore, "funcall", rather than
> "send", should be understood to include private methods.


I think "funcall" is just an artifact of the rb_funcall()
function---which invokes a method on an _explicit_ receiver---from
Ruby's C interface.

--
Posted via http://www.ruby-forum.com/.

 
Reply With Quote
 
 
 
 
Trans
Guest
Posts: n/a
 
      12-31-2006

http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Hi --
>
> On Sun, 31 Dec 2006, Daniel Schierbeck wrote:
>
> > I agree that `funcall' is a weird name... "call a function". What
> > function? I thought we agreed on calling them methods!

>
> I think the idea is that calling methods without a receiver can be
> considered "functional style"; therefore, "funcall", rather than
> "send", should be understood to include private methods.
>
> I'm not sure I find it very convincing. I think of the no-receiver
> thing as a way of un-cluttering the code a bit, not a departure from
> object orientation. After all, there *is* a receiver, and it is
> receiving a message.
>
> Also, funcall itself does involve a receiver. So the situation is
> that you see this:
>
> obj.funcall(:meth)
>
> and you infer that it includes private methods because *if* you were
> calling meth as a private method, there would be no receiver. To me
> that involves too much "What if?"



Hmm... Are you perhpas indirectly suggesting:

send(:meth) # private
self.send(:meth) # public

?

T.


 
Reply With Quote
 
Devin Mullins
Guest
Posts: n/a
 
      12-31-2006
Trans wrote:
> Hmm... Are you perhpas indirectly suggesting:
>
> send(:meth) # private
> self.send(:meth) # public
>
> ?


Yikes, a method that behaves differently depending on how it's called?
What about method(:send).call vs self.method(:send).call?

Meprefers send_priv or something.

Devin
(And I think David was just trying to guess at the reasoning behind the
name "funcall" [I'd imagine better explained by rb_funcall], and then
disagreeing with the reasoning.)

 
Reply With Quote
 
Eric Hodel
Guest
Posts: n/a
 
      12-31-2006
On Dec 30, 2006, at 14:47, Daniel Schierbeck wrote:

> I agree that `funcall' is a weird name... "call a function". What
> function? I thought we agreed on calling them methods!


Why? It looks like a function call as there is no receiver.

obj.foo() # method call, receiver is obj

foo() # function call, no receiver

private methods must be called like functions, not like methods.

--
Eric Hodel - (E-Mail Removed) - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!


 
Reply With Quote
 
Rob Sanheim
Guest
Posts: n/a
 
      12-31-2006
On 12/31/06, Devin Mullins <(E-Mail Removed)> wrote:
> Trans wrote:
> > Hmm... Are you perhpas indirectly suggesting:
> >
> > send(:meth) # private
> > self.send(:meth) # public
> >
> > ?

>
> Yikes, a method that behaves differently depending on how it's called?
> What about method(:send).call vs self.method(:send).call?
>
> Meprefers send_priv or something.
>
> Devin


What about:

obj.send(:foo) # will call only public
obj.send!(:foo) # will bypass private/protected, like the current send.

reads better then funcall to me, at least.
- Rob

 
Reply With Quote
 
Wilson Bilkovich
Guest
Posts: n/a
 
      12-31-2006
On 12/31/06, Rob Sanheim <(E-Mail Removed)> wrote:
> On 12/31/06, Devin Mullins <(E-Mail Removed)> wrote:
> > Trans wrote:
> > > Hmm... Are you perhpas indirectly suggesting:
> > >
> > > send(:meth) # private
> > > self.send(:meth) # public
> > >
> > > ?

> >
> > Yikes, a method that behaves differently depending on how it's called?
> > What about method(:send).call vs self.method(:send).call?
> >
> > Meprefers send_priv or something.
> >
> > Devin

>
> What about:
>
> obj.send(:foo) # will call only public
> obj.send!(:foo) # will bypass private/protected, like the current send.
>
> reads better then funcall to me, at least.


Yes please. That's perfect.

 
Reply With Quote
 
Eric Hodel
Guest
Posts: n/a
 
      12-31-2006
On Dec 31, 2006, at 24:04, Wilson Bilkovich wrote:
> On 12/31/06, Rob Sanheim <(E-Mail Removed)> wrote:
>> obj.send(:foo) # will call only public
>> obj.send!(:foo) # will bypass private/protected, like the current
>> send.
>>
>> reads better then funcall to me, at least.

>
> Yes please. That's perfect.


No please. That doesn't match the behavior of any other #foo, #foo!
that I know of. #send and #funcall match what the written methods
look like perfectly.

--
Eric Hodel - (E-Mail Removed) - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!


 
Reply With Quote
 
Trans
Guest
Posts: n/a
 
      12-31-2006


On Dec 31, 3:34 am, Eric Hodel <(E-Mail Removed)> wrote:
> On Dec 31, 2006, at 24:04, Wilson Bilkovich wrote:
>
> > On 12/31/06, Rob Sanheim <(E-Mail Removed)> wrote:
> >> obj.send(:foo) # will call only public
> >> obj.send!(:foo) # will bypass private/protected, like the current
> >> send.

>
> >> reads better then funcall to me, at least.

>
> > Yes please. That's perfect.No please. That doesn't match the behavior of any other #foo, #foo!

> that I know of. #send and #funcall match what the written methods
> look like perfectly.


The problem with #send and #funcall (or #send!) is that these are VIMs
(very important methods). They aren't to be overwritten lightly, if at
all, which is evident by the fact that we also have __send__ in case
that it is. So any generic piece of meta-programming ends up using
__send__ anyway. Throw in __funcall__ and now we have four methods when
two would do. So besides the fact that this straddles us with two
completely different terms for nearly the exact same thing, which is
bad enough, it does nothing to alleviate this more fundamental issue.

T.


 
Reply With Quote
 
dblack@wobblini.net
Guest
Posts: n/a
 
      12-31-2006
Hi --

On Sun, 31 Dec 2006, Rob Sanheim wrote:

> On 12/31/06, Devin Mullins <(E-Mail Removed)> wrote:
>> Trans wrote:
>> > Hmm... Are you perhpas indirectly suggesting:
>> >
>> > send(:meth) # private
>> > self.send(:meth) # public
>> >
>> > ?

>>
>> Yikes, a method that behaves differently depending on how it's called?
>> What about method(:send).call vs self.method(:send).call?
>>
>> Meprefers send_priv or something.
>>
>> Devin

>
> What about:
>
> obj.send(:foo) # will call only public
> obj.send!(:foo) # will bypass private/protected, like the current send.
>
> reads better then funcall to me, at least.


Me too -- that was what I suggested long ago Matz didn't feel it
corresponded to his concept of a ! (dangerous) method.


David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
(See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: its the little things that count OldGringo38 Computer Support 17 08-02-2010 10:36 PM
Re: its the little things that count OldGringo38 Computer Support 8 08-01-2010 05:43 PM
1 little 2 little 3 little Kennedys dale Digital Photography 0 03-23-2008 01:03 PM
vs2005 publish website doing bad things, bad things =?Utf-8?B?V2lsbGlhbSBTdWxsaXZhbg==?= ASP .Net 1 10-25-2006 06:18 PM
It's the little things that make the difference Philip NZ Computing 5 06-19-2006 01:32 AM



Advertisments