Re: Re: static versus dynamic typing policy

On 18 Feb 2005, at 13:54, Martin C. Martin wrote:

>
>
> Pascal DeMilly wrote:
>
>> On Fri, 2005-02-18 at 01: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.
>> Personally I disagree in forcing me to put () after anything. As the
>> script writer let me make that decision. I got bitten by the size and
>> size() ambiguities but it didn't kill me. For the most part, there is 
>> no
>> ambiguities and it looks so much better.
>> Go and explain an end-user the difference between a property and a
>> method. I believe Groovy has a great future in being a plugin language
>> for end user wanting more from their application as well as a 
>> scripting
>> language for developer
>
> Personally I agree with Pascal that parens should be optional, even 
> for 0-arg methods.  I don't think "is weird & feels strange" is a good 
> enough reason; the question is not your first reaction, but whether 
> you'll get used to it after a couple months and it will feel natural. 
> When I moved from Applesoft Basic, where line numbers were central, to 
> Amiga Basic, which didn't have line numbers, it felt weird and strange 
> -- for a few days.
>
> I see no reason property vs. field vs. method shouldn't be an 
> implementation detail.  foo.bar does some things and returns a result. 
> Why does it matter what goes on under the hood?  If you want the user 
> to think of one as a property/field, and the other as an action, then 
> use a noun phrase for the first and a verb phrase for the second.  
> Thus bar vs. getBar/toString.

FWIW we could still say that this is true from a language perspective...

foo.bar // property
foo.bar() // method

and the runtime could, if we want it to, expose zero argument methods 
as properties. i.e. if there is no property available for a name, try a 
zero arg method of the same name. So you could

foo.toString

Its more a question of would folks think this is weird; as that'd open 
the door to strange code such as

foo.bar
foo.getBar
foo.getBar()

all being interchangeable. So I'm thinking we should be a little 
careful with zero arg methods to avoid polluting the namespace too 
much.

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