On Jan 31, 2005, at 6:40 PM, Trans wrote:

> ...There are times when
> I just want one method that does a number of different but related
> things...

I gotta say wrt your original motivation, to me the need for this 
"feature" reeks of bad design. Even ignoring Eric's appeal for 
readability/separation of tokens, wanting a single method that "does a 
number of different but related things" says to me that maintainability 
and comprehensibility is going to be sacrificed in the medium-to-long 
run.

It encourages cramming another handler into an existing method when 
writing a new method is the appropriate thing to do. Documentation? 
Unit testing??? Gah.

And parsability??

You are asking the parser to differentiate var.method:arg.method 
between var.method(:arg).method and var.method(:arg.method) based on 
(I'm guessing) the context of already being within a method call. 
You'll break _all_ existing code that reads var.method arg.method.

I don't see how, given the original example and the followups, the 
benefits outweigh the costs.