jastrachan | 11 Jan 10:18 2005
Picon

Re: [groovy-dev] RFE javadoc like reflection syntax

On 10 Jan 2005, at 11:00, Jochen Theodorou wrote:
> jastrachan@... schrieb:
>> On 9 Jan 2005, at 19:30, John Wilson wrote:
>>>
>>> On 9 Jan 2005, at 18:30, Jochen Theodorou wrote:
>>>
>>>> Currently we have a problem in Groovy:
>>>>
>>>> class Foo1 {
>>>>   void h(){}
>>>> }
>>>>
>>>> f = new Foo1()
>>>> c = f.h
>>>> println c
>>>>
>>>> you will see c is a closure - but:
>> Yes - I think this is confusing - we agreed this at the JCP meeting -  
>> that to get a closure for some method of a certain name, we should  
>> add some new helper method. So when we make this change, f.h would do  
>> as you suspect - or throw an exception saying no such  
>> property/method.
>> To get a closure to the method, we'd need to do something like
>> c.methodPointer("h")
>> or whatever we call the new helper method
>
> why there is a need for this? If this is needed why not using some  
> syntax for it. If is not needed why adding it?

Its a useful thing; turning a method on an object into a closure; its  
kinda like currying, kinda.

the question is, is this so common such that we need a new language  
syntax for it - or is it just a helper method we add somewhere. To  
start with we used the existing property notation syntax - which I  
think is a big mistake with hindsight. I'm suggesting now we roll this  
back (as its caused nothing but confusion) and add a helper method for  
when people want this feature.

>
> [...]
>>> Class Foo {
>>>     int h = 1
>>>     int getH() { return 100}
>>>     int h() { return 200}
>>>     String h(String s) {return s}
>>> }
> [...]
>>> If these problems have been fixed then your notation is redundant.
>> Yes, you're correct. The thing which is not completely clear is which  
>> should be chosen, the property (getH()) or the method (h). My gut  
>> feel is that it should always go for the property first, since thats  
>> the common use case of the normal property syntax. foo.h is by  
>> default a property accessor and it would only use h() if there was no  
>> property.
>
> shouldn't there be a way to explicitly choose one of the four? kicking  
> the closure thing for f.h would help much I think. Is it widely used?  
> Is it worth it?

See above.

> About the checking "property, field, method", I think this does making  
> sense, but it doesn't help to avoid parenthesis. If I'm not sure there  
> is a field or property of the same name, and I can't be sure I ahve to  
> use the parenthesis. So at last we should add this problem to the  
> language guide.

To disambiguate between a field and property, we're considering using  
foo. <at> h to be explit that you don't wanna use th property.

A more complete example here...

http://docs.codehaus.org/display/GroovyJSR/ 
field%2C+property%2C+method+disambiguation

> [...]
>> Well firstly, foo.methods in the new language would still work as  
>> expected - as the 2 fields are private by default; you need to add  
>> the keyword 'property' to make them public bean properties.
>
> how about accesing it from inside the class, or making the fields  
> protected/public?

I was assuming in the above that the visibility was such that you'd  
only see fields if they were visible.

>> To access the underlying methods/fields if you have a naming clash,  
>> you can always get them from the MetaClass. Otherwise, if you  
>> overload some methods with something else, what do you expect :)
>> So if you do decide to overload 'methods'; you can do  
>> foo.metaClass.methods
>
> But then we could kick this also. And why foo.metaClass? foo.class is  
> possible right?

Sure

> But we should change Foo.class so it returns Foo, then there are many  
> issues fixed

It does?

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


Gmane