From: "T. Onoma" <transami@...>
Date: 2003-11-28T17:00:20+09:00
Subject: Re: Controlled block variables

On Friday 28 November 2003 04:59 am, Gavin Sinclair wrote:
> Maybe - I'm not sure - you're under the misunderstanding that, or maybe
> you're proposing that the following should occur:
>
>   class Example
>     def ameth(x)
>       x + 1
>     end
>   end
>
>   e = Example.new
>
>   e.ameth    # returns Proc
>              # return value equiv. to proc { |x| x + 1 }
>
>   # Instead of
>   # e.ameth       -> ArgumentError: 0 for 1
>
> This is the "methods as first class objects" wish that Python implements.
> Is that what you're proposing?  If so, I missed it or misunderstood it in
> previous messages.

Like I said, I may be overlooking something obvious here, but what i mean is 
this:

   class Example
     def ameth
       proc { |x| x + 1 }
     end
   end

   e = Example.new

   e.ameth    # return equiv. to proc { |x| x + 1 }

   # But...
   e.ameth(2)  # -> 3

In otherwords, Ruby wouldn't assume that the arity is automatically wrong, but 
rather that the method may return a proc (or method) to which the parameters 
can be applied. Granted, this may mean the possibility of not so obvious 
errors when it is not the case. And like I said, there may be something I'm 
overlooking that makes this impossible. But that's the thought I'm having, 
anyway. It further means that

   e.ameth()(2)  # -> 3

actually means something --it is the "unambiguous" form of the above.

> I sympathise with the wish that methods be first class, and that you can
> pass them around, but when I red Jim Weirich's article
> (http://onestepback.org/index.cgi/Tech/Ruby/PythonAndRuby.rdoc) that door
> forever closed in my mind.

That's what I read. And I'm not really suggesting that they be first class 
objects. Only that Ruby might be able to "fake it", so to speak.

> If you can clear up the misunderstandings I have about where you're coming
> from, I'd like to hear your proposals.

I truly appreciate your interest, Gavin.

Thanks,
-t0