On Fri, 7 Jul 2006 dblack / wobblini.net wrote:

> 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
-- 
suffering increases your inner strength.  also, the wishing for suffering
makes the suffering disappear.
- h.h. the 14th dali lama