Re: [groovy-jsr] Proposal to Improve @Property Syntax

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
51 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [groovy-jsr] Proposal to Improve @Property Syntax

Guillaume Laforge
Administrator
As I said it on the other list, I think the proposition is pretty good.
So I also support this proposal, despite the fact I was a bit
reluctant to make such a change that near of our RC-X and upcoming
final release.
But I'd be glad to get some feedback from our users too -- that's why
I've cc'ed the user list.

On 3/5/06, Dierk Koenig <[hidden email]> wrote:

> I support the proposal by tug/graeme and would like to rephrase it as
> follows:
> - if a field is defined with default visibility, it is considered to be
>   of 'property' visibility
> - fields with 'property' visibility get the according accessor methods
>   generated in the bytecode
> - the special case of 'property' visibility in combination with the
>   'final' keyword leads to only have the getter but no setter method
>   to be generated
>
> Mittie
>
> > -----Original Message-----
> > From: [hidden email] [mailto:[hidden email]]On Behalf
> > Of Graeme Rocher
> > Sent: Sonntag, 5. März 2006 14:26
> > To: [hidden email]
> > Subject: [groovy-jsr] Proposal to Improve @Property Syntax
> >
> >
> > Hi all,
> >
> > Please find below proposals to improve the @Property syntax, this is
> > being posted to the JSR list to open discussions on moving the change
> > forwrad.
> >
> > Cheers
> > Graeme
> >
> >
> > A recent blog post did high light the one thing I think is "ugly"
> > about Groovy. The @Property syntax. So I want raise a topic about this
> > an see if anything comes out of it.  Originally i thought the syntax
> > was created because we didn't want to introduct keywords that
> > conflicted with java, but clearly this is not the case as we have
> > 'def' and others.
> >
> > Graeme
> >
> >
> > I must agree with you, Graeme - the @Property thing is nasty. It's is
> > especially unfortunate as the a.@b notation specified that b is *not*
> > a property.
> >
> > I have a rather radical suggestion:
> >
> >
> > def x
> >
> > is equivalent to
> >
> > private x
> >
> > public getx() {...
> >
> > public setx(x) {....
> >
> > and
> >
> > final x = 1
> >
> > is equivalent to
> >
> > private final x = 1
> >
> > public getx() {...
> >
> > and
> >
> > public x, protected x and private x define public, private and
> > protected fields
> >
> > If users need to define protected or private acessor functions they
> > have to do so explicitly.
> >
> > There seems to be two forms of breakage if we were to do this:
> >
> > 1/ calling Groovy from Java would cause the Java code to fail to
> > compile.
> >
> > 2/ People doing wacky stuff with metaclasses would see silent
> > breakage if they were relying on catching the access to the field.
> >
> > In my view neither of these breakages are bad enough to prevent us
> > doing this.
> >
> >
> > John Wilson
> > The Wilson Partnership
> > http://www.wilson.co.uk
>
>


--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: [groovy-jsr] Proposal to Improve @Property Syntax

Scott Hickey-3
This shouldn't be a huge change for most existing code. For existing simple bean classes with properties were defined like below, removing @Property results in the class
@Property Integer id
@Property String description

For existing service or utility classes, a scope qualifier (public, protected, private) would need to be added to prevent an accessor and mutator from being automatically generated.


Guillaume Laforge <[hidden email]> wrote:
As I said it on the other list, I think the proposition is pretty good.
So I also support this proposal, despite the fact I was a bit
reluctant to make such a change that near of our RC-X and upcoming
final release.
But I'd be glad to get some feedback from our users too -- that's why
I've cc'ed the user list.

On 3/5/06, Dierk Koenig wrote:

> I support the proposal by tug/graeme and would like to rephrase it as
> follows:
> - if a field is defined with default visibility, it is considered to be
> of 'property' visibility
> - fields with 'property' visibility get the according accessor methods
> generated in the bytecode
> - the special case of 'property' visibility in combination with the
> 'final' keyword leads to only have the getter but no setter method
> to be generated
>
> Mittie
>
> > -----Original Message-----
> > From: [hidden email] [mailto:[hidden email]]On Behalf
> > Of Graeme Rocher
> > Sent: Sonntag, 5. März 2006 14:26
> > To: [hidden email]
> > Subject: [groovy-jsr] Proposal to Improve @Property Syntax
> >
> >
> > Hi all,
> >
> > Please find below proposals to improve the @Property syntax, this is
> > being posted to the JSR list to open discussions on moving the change
> > forwrad.
> >
> > Cheers
> > Graeme
> >
> >
> > A recent blog post did high light the one thing I think is "ugly"
> > about Groovy. The @Property syntax. So I want raise a topic about this
> > an see if anything comes out of it. Originally i thought the syntax
> > was created because we didn't want to introduct keywords that
> > conflicted with java, but clearly this is not the case as we have
> > 'def' and others.
> >
> > Graeme
> >
> >
> > I must agree with you, Graeme - the @Property thing is nasty. It's is
> > especially unfortunate as the a.@b notation specified that b is *not*
> > a property.
> >
> > I have a rather radical suggestion:
> >
> >
> > def x
> >
> > is equivalent to
> >
> > private x
> >
> > public getx() {...
> >
> > public setx(x) {....
> >
> > and
> >
> > final x = 1
> >
> > is equivalent to
> >
> > private final x = 1
> >
> > public getx() {...
> >
> > and
> >
> > public x, protected x and private x define public, private and
> > protected fields
> >
> > If users need to define protected or private acessor functions they
> > have to do so explicitly.
> >
> > There seems to be two forms of breakage if we were to do this:
> >
> > 1/ calling Groovy from Java would cause the Java code to fail to
> > compile.
> >
> > 2/ People doing wacky stuff with metaclasses would see silent
> > breakage if they were relying on catching the access to the field.
> >
> > In my view neither of these breakages are bad enough to prevent us
> > doing this.
> >
> >
> > John Wilson
> > The Wilson Partnership
> > http://www.wilson.co.uk
>
>


--
Guillaume Laforge
Groovy Project Manager
http://glaforge.free.fr/blog/groovy


Yahoo! Mail
Use Photomail to share photos without annoying attachments.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: [groovy-jsr] Proposal to Improve @Property Syntax

Marc Palmer Local
In reply to this post by Guillaume Laforge

On 6 Mar 2006, at 20:01, Guillaume Laforge wrote:

> As I said it on the other list, I think the proposition is pretty  
> good.
> So I also support this proposal, despite the fact I was a bit
> reluctant to make such a change that near of our RC-X and upcoming
> final release.
> But I'd be glad to get some feedback from our users too -- that's why
> I've cc'ed the user list.
>
I've just had a thought about this...

> On 3/5/06, Dierk Koenig <[hidden email]> wrote:
>> I support the proposal by tug/graeme and would like to rephrase it as
>> follows:
>> - if a field is defined with default visibility, it is considered  
>> to be
>>   of 'property' visibility
>> - fields with 'property' visibility get the according accessor  
>> methods
>>   generated in the bytecode
>> - the special case of 'property' visibility in combination with the
>>   'final' keyword leads to only have the getter but no setter method
>>   to be generated

I think the last feature - final/read-only properties - is  
problematic in semantic terms.

A read-only property may still have a value that changes over time  
surely? For example a class MyGroovyCalendar might have a "today"  
read only property with a getToday() getter.

This value is definitely not final although it is read only, hence  
use of the "final" keyword here is confusing and contradictory. In  
Java (and the rest of groovy as I understand it), final always means  
final.

Therefore I am personally not happy with the use of "final" in this way.

How about something else, albeit imperfect, such as: if you define an  
explicit getter for the property it suppresses implicit setter  
generation? i.e:

class MyGroovyCalendar
{
        Date today

        Date getToday()
        {
                return today
        }
}

This would make the property read only, by suppressing the setter  
generation.

Visually it seems to make sense to me also, there is obviously no  
setter code in the source. The only issue here is how to make a write-
only property... does declaring a setter prevent an implicit getter  
being generated? I think there is an argument against this, as  
typically setters may have side effects but getters often continue to  
just read the field value. However having asymmetric behaviour in  
this regard might be too confusing.

Perhaps defining any explicit getter OR setter should disable  
automatic generation of the other? I think this is consistent and  
only slightly tedious, unless you have a lot of setters with side  
effects.

What do you think?


~ ~ ~
Marc Palmer ([hidden email])
Consultant/Analyst
AnyWare Ltd.
http://www.anyware.co.uk/

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: [groovy-jsr] Proposal to Improve @Property Syntax

tugwilson

On 7 Mar 2006, at 10:46, Marc Palmer wrote:

>
> I think the last feature - final/read-only properties - is  
> problematic in semantic terms.
>
> A read-only property may still have a value that changes over time  
> surely? For example a class MyGroovyCalendar might have a "today"  
> read only property with a getToday() getter.
>
> This value is definitely not final although it is read only, hence  
> use of the "final" keyword here is confusing and contradictory. In  
> Java (and the rest of groovy as I understand it), final always  
> means final.
>
> Therefore I am personally not happy with the use of "final" in this  
> way.


Marc,

The original proposal said...

final x = 1

is equivalent to

private final x = 1

public getx() {...


So the private field is final.

I think these semantics are compatible with the java ones (i.e. that  
a final value can have at most two observable values).


John Wilson
The Wilson Partnership
http://www.wilson.co.uk


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: [groovy-jsr] Proposal to Improve @Property Syntax

Marc Palmer Local
>
> Marc,
>
> The original proposal said...
>
> final x = 1
>
> is equivalent to
>
> private final x = 1
>
> public getx() {...
>
>
> So the private field is final.
>
> I think these semantics are compatible with the java ones (i.e.  
> that a final value can have at most two observable values).

Sorry that last bit has me a bit flummoxed. 2 values for a final in  
Java? I've not consciously come across that before - and even if its  
true it sounds contradictory unless one is "undefined" and the other  
the final value.

How, using your proposal, would we implement a read only property  
with a non-final value? i.e. the Java equivalent of this:

public class MyJavaClass
{
        private int value;

        public int getValue() { return value; }
}

I would have thought that a simple way to implement this would be  
very desirable in groovy, and my gut tells me anything involving  
"final" is not a nice solution.

Cheers

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Re: [groovy-jsr] Proposal to Improve @Property Syntax

Jon Skeet
In reply to this post by Guillaume Laforge
> > So the private field is final.
> >
> > I think these semantics are compatible with the java ones (i.e.  
> > that a final value can have at most two observable values).
>
> Sorry that last bit has me a bit flummoxed. 2 values for a
> final in Java? I've not consciously come across that before -
> and even if its true it sounds contradictory unless one is
> "undefined" and the other the final value.

The variable can be observed with its default value before the variable
is initialized. Here's an example:

public class Test
{
    final int x;

    private Test()
    {
        showX();
        x = 5;
        showX();
    }
   
    private void showX()
    {
        System.out.println (x);
    }
   
    public static void main(String[] args)
    {
        new Test();
    }
}

Jon


Clearswift monitors, controls and protects all its messaging traffic in compliance with its corporate email policy using Clearswift products.
Find out more about Clearswift, its solutions and services at http://www.clearswift.com

This communication is confidential and may contain privileged information intended solely for the named addressee(s). It may not be used or disclosed except for the purpose for which it has been sent. If you are not the intended recipient, you must not copy, distribute or take any action in reliance on it. Unless expressly stated, opinions in this message are those of the individual sender and not of Clearswift. If you have received this communication in error, please notify Clearswift by emailing [hidden email] quoting the sender and delete the message and any attached documents. Clearswift accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Clearswift domain.

This footnote confirms that this email message has been swept by MIMEsweeper for Content Security threats, including computer viruses.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Re: [groovy-jsr] Proposal to Improve @Property Syntax

Antti Karanta
In reply to this post by Guillaume Laforge

> Perhaps defining any explicit getter OR setter should disable  
> automatic generation of the other? I think this is consistent and  
> only slightly tedious, unless you have a lot of setters with side  
> effects.

  I'd prefer something simple in the spirit of Ruby's attr_writer,
attr_reader and attr_accessor.

  If the @Property syntax is kept, it would mean read-write property (as
it has to this point, i.e. this is backwards compatible).
@Property('r')  x  // generates only the getter
@Property('w')  x  // generates only the setter
@Property('rw') x  // generates both getter and setter

  If the @Property syntax is what we want to get rid of, then maybe
something like

property   x // read-write property
rproperty  x // read only property
wproperty  x // write only property
rwproperty x // read-write property (same as with property keyword)

  The names proposed here may not be ideal, but something like this
would be nice.



       -Antti-


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: [groovy-jsr] Proposal to Improve @Property Syntax

tugwilson
In reply to this post by Marc Palmer Local

On 7 Mar 2006, at 11:26, Marc Palmer wrote:

> How, using your proposal, would we implement a read only property  
> with a non-final value? i.e. the Java equivalent of this:
>
> public class MyJavaClass
> {
> private int value;
>
> public int getValue() { return value; }
> }
>
> I would have thought that a simple way to implement this would be  
> very desirable in groovy, and my gut tells me anything involving  
> "final" is not a nice solution.


You do exactly the same in Groovy to get the same effect.


John Wilson
The Wilson Partnership
http://www.wilson.co.uk


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: [groovy-jsr] Proposal to Improve @Property Syntax

tugwilson
In reply to this post by Jon Skeet

On 7 Mar 2006, at 11:59, Jon Skeet wrote:

> The variable can be observed with its default value before the  
> variable
> is initialized. Here's an example:


Exactly Jon - thanks for the example.


John Wilson
The Wilson Partnership
http://www.wilson.co.uk


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: [groovy-jsr] Proposal to Improve @Property Syntax

Marc Palmer Local
In reply to this post by tugwilson

On 7 Mar 2006, at 12:13, John Wilson wrote:

>
> On 7 Mar 2006, at 11:26, Marc Palmer wrote:
>
>> How, using your proposal, would we implement a read only property  
>> with a non-final value? i.e. the Java equivalent of this:
>>
>> public class MyJavaClass
>> {
>> private int value;
>>
>> public int getValue() { return value; }
>> }
>>
>> I would have thought that a simple way to implement this would be  
>> very desirable in groovy, and my gut tells me anything involving  
>> "final" is not a nice solution.
>
>
> You do exactly the same in Groovy to get the same effect.

OK, so the Groovy property mechanism offers nothing in this situation.

All we're talking here then is a mechanism, via no specified  
visibility keyword, to indicate to groovy that it should auto  
generate public getter AND setter and to use a private field for the  
value.

Anything outside of this functional scope, such as read only or write  
only properties requires a conventional manual-definition approach.

In this respect it is certainly less ugly than the @Property  
"annotation". However the trade off is that if an annotation/keyword  
is retained we could add in more flexibility such as support for read  
only properties with auto generated getters.

I suppose if a specific notation was retained this could open the  
door to supply of property metadata (i.e. generated of BeanInfo  
classes) with info such as property descriptions etc.

Is this something that would be useful on Groovy's future roadmap? If  
so, I imagine keeping a specific property declaration syntax might be  
helpful - i.e.

class MyClass
{
        @Property("The important value, which is used for things")
        int importantValue

        @Property(readonly, "The important read only value")
        int importantValue2
}


Marc

1234 ... 6
Loading...