> It seems to me that the simplest disambiguating rule is to require the > parentheses on methods.
The way I see it, any sort of matching of what [multi-]?method is to be called, is automatically doomed to failure. But I don't think that means we need to require parentheses, except to override the default behaviour. There are three meanings I can see for parenthesisless calls that are completely regular and meaningful, easy to read, and quite (debatably) good things. 1) Always assume nulladic. That is, $obj.id is always parsed exactly like $obj.id(). The advantage here is that short simple things can be written short and simply. 2) Always assume monadic. Personally, I don't think this would be that useful, but I'm mentioning it for completeness. Any call that doesn't have parentheses scoops up the next argument only. 3) Always assume variadic. Basically a lot like the perl5 rule. If you call something without parentheses, the parser puts parentheses around pretty much everything after it. If you don't like it, put your own parentheses where you really want them. So foo bar baz quux; would be parsed as foo(bar(baz(quux()))); and foo bar, baz; would be exactly like foo(bar(), baz()); and if foo is later determined to be something that can only take one argument, well then too bad. The idea is that leaving off the parentheses is just shorthand, and doesn't need to do any lookup to determine whether what's typed is valid, any more than if you had typed foo(bar(), baz()); If you want foo to be monadic, call it as "foo(bar), baz"; or the lispy "(foo bar), baz;" (with optional parens after bar and baz, since they don't have anything more they could eat anyway, unless someone gets crazy enough to write a unary comma operator). So basically we can leave off the parentheses in the usual cases, but they're still required when you're doing something unusual or that would otherwise be hard to read. -- Adam Lopresto ([EMAIL PROTECTED]) http://cec.wustl.edu/~adam/ "I have a very firm grasp on reality! I can reach out and strangle it any time!"