Re: Re: static versus dynamic typing policy

On 14 Feb 2005, at 17:13, Guillaume Laforge wrote:
> James ?
>
>> In fact, James thought we could allow optional parentheses in two  
>> cases only:
>> - when the last parameter or single parameter of a method call is a
>> closure, like col.each{}
>> - when it's a top-level statement, like println "foo"
>>
>> We need a firm and definitive decision on that item.
>
> What's your opinion on this?

I think the confusion/pushback seems to be on methods-with-no-args  
appearing as properties.

e.g. this feels natural...

foo.bar // property bar or field maybe
foo.getBar() // getter

but

foo.getBar
foo.toString

is weird & feels strange

Optional parens when there is one or more arguments (including  
closures) look & feel like method calls. Making methods with void  
arguments look like properties feels a bit strange really - so I'm  
thinking we should maybe enforce parens on zero argument method calls  
to disambiguate them from properties.

There's a TCK test case which demonstrates how we currently  
disambiguate fields, properties and methods which illustrates the  
point...

http://cvs.groovy.codehaus.org/viewrep/groovy/groovy/jsr/tck/test/misc/ 
FieldPropertyMethodDisambiguationTest.groovy?r=HEAD

The converse case to this, there are many pseudo properties out there  
in the JDK which aren't really Java properties such as  
Collection.size() or String.length() - but I guess we could always use  
some kinda mechanism to 'fix' bad classes?

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