jastrachan | 18 Feb 12:20 2005

Re: Re: static versus dynamic typing policy

On 18 Feb 2005, at 09:47, Russel Winder wrote:
> On Fri, 2005-02-18 at 08:10 +0000, jastrachan@... wrote:
>> foo.bar // property bar or field maybe
>> foo.getBar() // getter
>> but
>> foo.getBar
>> foo.toString
>> is weird & feels strange
> Personally I agree with you on this but this is just my opinion.  I
> would like to have the () after to show they are method calls.


The converse to this is there are many 'almost properties' in the JDK  
which it'd be nice to expose as properties.

>> 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.
> I am not sure about this.  In functional languages that use Currying it
> is natural to see "f x y z" since "f ( x , y , z )" would be something
> totally different -- the first is a function that will eventually deal
> with three argument whereas the second is a function of one argument
> that is a tuple.  For me seeing something like:
> 	foo.toString "blah"
> is different but I could get used to it.  The real question is only
> whether there is consistency and simplicity of rules.  Mike is
> definitely right when he said where there are many complex rules that
> have tortuous interrelationships then there is a serious problem.


>> 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
> Is there any way of creating a semantic so that we can lose the  <at> ?  I
> know Ruby does this sort of thing and Perl is famous for it -- but then
> Perl is an execute only language after all :-)

Note that the  <at> foo isn't really required for 95% of programs; its just  
there if someone wants to be really really specific.

>> 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?
> I am not sure it should be a goal for Groovy to fix Java's problems.
> The fact that an inconsistency in Java has to be presented in Groovy
> does not make it a problem for Groovy.

Agreed. I don't think we should fudge Groovy to cover up some bad  
classes in the JDK - I'm more concerned with a simple, concise and  
powerful core language. Though we have already started making the JDK  
more groovy, so it'd be nice to fix the broken 'beans' - however I'm  
totally happy with making that a 2.0 goal/feature so we can punt on it  
for now.