From: Michael Neumann <uu9r@...>
Date: 2003-11-28T21:22:17+09:00
Subject: Re: Controlled block variables

T. Onoma wrote:
> 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

What's wrong with

     e.ameth[2]

?

Your proposal means that () should be an operator that could be overloaded as
it is the case in C++ or Python (?). But this leads to lots of confusion and
IMHO doesn't give so many advantages. Indeed, this would make the program much
less readable, as you would not be able to distinguish between method calls and
other things.

Unlike Python, we don't really have functions. Ruby is pure OO! So (almost)
everything is a method call, except e.g. (), which is required to group
parameters for a method call.

> 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

What should happen if the method do not return a proc, but e.g. an integer?
How should Ruby know in advance what you're actually returning from the method?
You can't decide this before actually executing it. You would need to execute
the method first with no arguments, to then decide that it does not return a
proc and then fail. That's pretty ugly, IMO. 

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

What's the advantage here. Why not simply use

     e.ameth()[2] 

or 

     e.ameth[2] 

Both do not introduce any ambiguity. And why is a proc special at all? It's an
object like any other. Then you'd have to use the same syntax for Array, Hashes
and so on, too.  

Proc's can be used as virtual arrays, so it's good that they respond to the
same method [] as Arrays or Hashes do.


Regards,

  Michael