From: "Aleksi Niemelä" <aleksi.niemela@...>
Date: 2000-07-19T12:04:01+02:00
Subject: [ruby-talk:04125] Re: Function objects. was: What are you usi	ng Ruby for?

Dave's solution:
>   calc2 = Calculator.new(1.4)
> 
>   register_function("f2", calc2.method(:f2), "computer it")
>   register_function("g2", calc2.method(:g2), "computer other")

This is nice.

For Clemens and Johann I'd like to say "beware procs"! They are deceptive.
Of course, despite this they marvellous :).

I thought originally that these are the differences between methods and
blocks:

                      Method                    Block
                      ------------------------------------------
  Naming              named                     anonymous
  Association         associated to a class     unassociated
  Variable binding    no binding                binds

But there're some "hidden" features too:

  Parameter passing   all supported ways        only plain  (*)
  Return value        multiple returns or       last evaluation
                      last evaluation
  Block association   when calling              when created

  *) no optional, grouped (*rest) or named parameters allowed, 
     nor block block association

So for anything but reasonable simple "procedures" one could not use proc as
a method. Generally method can't be written as a proc without changing it's
interface (parameter passing, block association) and inner logic (multiple
return -> last evaluation).

Block, however, can be written as a method if it is not binding any data it
operates on.

I'm sure all these are well thought features, but for me the Perl way seems
much clearer. In Perl on the language level closures are written as an
anonymous subroutines (and they bind). Therefore switch between 

  named and referenced                  sub foo{} $foo=\&foo;   and 
  anonymous, binding, and referenced    $foo=sub {};

is a snap. It's conceptually clear, simple and very well working solution.

Perhaps Matz wants to share some insight why blocks are working and done as
they are, and why they are inherently more complicated than Perl
"equivalent".

	- Aleksi