Re: Re: static versus dynamic typing policy

Agreed with all of that; I'm sure we can fix old JDK classes to expose 
what should be properties in a fairly simple way.

On 19 Feb 2005, at 01:01, John Rose wrote:
> On Feb 18, 2005, at 6:03, jastrachan@... wrote:
>> On 18 Feb 2005, at 13:54, Martin C. Martin wrote:
>>> Pascal DeMilly wrote:
>>> 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
>
> Question one:  Should the property-vs.-non-property intention be 
> reflected in the use-point syntax?
> Yes==Use-points are decorated to show intention, No==Lispy unification.
>
> Question two:  Should we act so that informal properties in imported 
> Java APIs be (usually) recognized as Groovy properties?
> Yes==A property by any other name would smell as sweet, No==Java Beans 
> uber alle.
>
> I'm struggling to understand all the little implications on the 
> design, but it's getting hard for me to avoid answering [yes, yes] to 
> [Q1, Q2].
>
> I care less about Q1 than about Q2, though I have my (Lisp-induced, 
> Java-anti-induced) tastes in the matter of Q1.
>
> About Q1:
>
> Martin and Pascal and I are relatively comfortable with the Lispy 
> answer "no, let us programmers inspect the name, to see what it 
> means".
>
> James, you don't like the implications of this, since it leads to two 
> ways to call a method.
> That can give people mixed signals (leading to cognitive dissonance 
> and the perception of ugliness):  x.burnDownTheHouse (property syntax, 
> method name).
>
> Some are willing to just deal with the mixed signals (basically 
> ignoring () when they read code).
> It probably irritates enough others that we need to get rid of the 
> mixed signals.
>
> For the record, we should knock this straw man down:
> Remove the mixed signals altogether by outlawing (not requiring or 
> optioning) empty parentheses.
> Have the parser recognize empty parens on calls enough to tell people 
> to get rid of them.
> Knockdown:  Too surprising for Java users, even worse than with 
> unpredictably mixed usage.
>
> Given the presence of the "()" signals, I think people's irritation at 
> their inconsistency means we are obligated to give some meaning to 
> them.
> The property-vs.-method distinction is the obvious meaning.
>
> About Q2:
>
>> So I'm thinking we should be a little careful with zero arg methods 
>> to avoid polluting the namespace too much.
> If we are obligated to distinguish properties from methods, then let's 
> think about ways to be careful with legacy Java APIs (while leaving 
> Groovy classes alone).
>
> Since many J2SE classes (perhaps even whole packages) use nullary 
> non-void methods to express properties, let's accept them as such 
> without individual annotation, subject to some restrictions:
>   - the class may not also contain "getX" methods
>   - the class may not be governed by other explicit Java Beans 
> machinery
>   - the class must be annotated as (potentially) having informal 
> properties
>   - the method itself must not be annotated as a non-property
>
> (The annotations will typically be injected by Groovy, sometimes on a 
> whole-package basis.  I think there is an ongoing attempt to 
> standardize on such annotations in Java, which Groovy must support 
> when it matures.)
>
>> foo.bar
>> foo.getBar
>> foo.getBar()
>>
>> all being interchangeable.
> Under the above rules, the existence of getBar protects bar in the 
> same class from being recognized as a property.
>
> The 'toString' and 'clone' methods would have to be annotated as 
> "not-a-property" in Object, which would protect all their overrides.
>
> -- John
>
>

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