jastrachan | 18 Feb 11:16 2005
Picon

Re: Re: static versus dynamic typing policy


On 18 Feb 2005, at 09:33, Russel Winder wrote:

> On Fri, 2005-02-18 at 08:51 +0000, jastrachan@... wrote:
>
>> // 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 :)
>
> But the & is optional in C and C++ so the classic groovy case is what
> most C / C++ programmers do.

I was thinking of the & in C++ to mean 'get the reference to something' 
or the 'address of something' (either on a type declaration or as an 
expression)

>  Also to be consistent with C / C++ would
> it be:
>
> 	foo = & System.out.println

You're right. Having .& is simpler to implement though - as we can use 
it in complex expressions

     foo(1234).&barMethod

> I am not so sure classic groovy causes confusion but I guess we would
> have to do a survey of some sort to have anything other than opinions
> and personal likes/dislikes.
> Unless there is a problem in having method pointers that conflicts with
> closures and things then I am quite comfortable with the classic groovy
> example.

I've seen quite a few mails on the dev/user list where folks got 
confused. I've got confused myself a few times.

The current classic behaviour is actually the same as Python and Python 
guys find it natural. However I think method pointers are a fairly rare 
feature, so I guess I just wanna make it hard to use by accident, using 
some kinda explicit syntax. I'm open to suggestions on nicer 
alternatives - I just think with fields/properties/methods we've enough 
overloading of

foo.someName

so we should just use some other syntax.

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


Gmane