--- Yukihiro Matsumoto <matz / ruby-lang.org> wrote:

> Hi,
> 
> In message "Re: will callable objects be more general in Ruby
> 1.9?"
>     on Fri, 27 May 2005 23:50:26 +0900, Eric Mahurin
> <eric_mahurin / yahoo.com> writes:
> 
> |> The priority idea is interesting.  My two concerns are:
> |> 
> |>   * it might make it hard for humans to understand what
> code does, by
> |>     introducing runtime ambiguity.
> |>   * I'm not sure if yacc allows that kind of priority
> resolution.
> |
> |I would assume it would be workable because you already have
> to
> |deal with priority between local variables and methods -
> "xyz"
> |will prefer accessing local variable xyz over calling method
> |"xyz".
> 
> But you can distinguish local variables and method
> invocations from
> the code, i.e. it is statically distinguishable at compile
> time.  If
> you want to "call" arbitrary expression,
> 
>   f.foo(1,2,3)
> 
> might mean either a) invocation of foo method on object f
> with
> argument (1,2,3) or b) invocation of "call" with argument
> (1,2,3) on
> object returned from "f.foo".  And there's no clue to
> distinguish them
> at compile time.
> 
> Only reasonable and generic solution is making method
> invocation model
> like Scheme's (or Python's), that is f.foo always return a
> method
> object, then (1,2,3) after the expression invokes the
> callable object
> with the arguments.  I don't want to choose this model for a
> few good
> reasons.  It's too big change to accomplish small generality.

I like the Scheme/Python way, but this would cause too many
problems with existing Ruby (force all method calls with no
args to use ()).

I was thinking that in the example above you would continue to
do what has always been done - call method f.foo with arguments
(1,2,3).  You would only "call" an object when what you are
calling looks like an expression or is only a local variable
(no method with same name).  So if you wanted to call the obect
returned from f.foo you'd have to do one of these:

f.foo()(1,2,3)
(f.foo)(1,2,3)

> |If this is still not wanted, another option would be to
> allow a
> |block to follow the [] operator (and be associated with it).
>  I
> |think this is a much smaller change to the language.
> 
> OK, I will consider this idea.
> 
> 							matz.

Thanks.  This might be more acceptable to many as some seem to
hate the idea of callable objects.



		
__________________________________ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail