jastrachan | 18 Feb 09:51 2005
Picon

Re: Re: static versus dynamic typing policy

On 14 Feb 2005, at 12:26, Guillaume Laforge wrote:
> James,
>
> Since you're back from you holidays, I'd like we bring that discussion 
> back:
>
> Do we allow calling parameter-less methods without parens?
>
> myObj.toString
>
> Is it a method closure? is it a field or property? or is it a method 
> call?

I think field/property feels right (as I've just said in a mail a few 
minutes ago)...

> I think it's aweful to overload the meaning of .xxxxx again.
> It's confusing enough. Those optional parenthesis make the code even
> harder to read in the case of more complex statements/expressions.
>
> James, didn't we agree on optional parenthesis being used only for
> top-level statements? (you said that some time ago, and this
> 'decision' is written somewhere in the IRC logs)
> Could you make a final call on that one, please?

Yes.

So only top level statements can omit parens. Maybe the rule should be 
'any top level method with arguments can omit parens'.

I've also said a few times that we should change the syntax of the 'get 
a method pointer' to something more explicit.

e.g.

// classic groovy
foo = System.out.println
foo("Hello")

is confusing. To get a method pointer (its not really a closure per se) 
we should introduce either a special method, or a new symbol. I'm 
tempted to use the old C/C++ style...

foo = System.out.&println
foo("Hello")

so that someone doesn't omit parens by accident and get really strange 
behaviour - it seems quite easy currently to use the name of a method 
rather than property, by accident, and have confusing results. So I 
definitely wanna remove this case. Methods v properties v fields are 
ambiguous enough without another case in there :)

James
-------
http://radio.weblogs.com/0112098/


Gmane