Re: will callable objects be more general in Ruby 1.9?

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 <[e-mail]> 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.

|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.