Proposal to Improve @Property Syntax

classic Classic list List threaded Threaded
114 messages Options
1234 ... 12
Reply | Threaded
Open this post in threaded view
|

Proposal to Improve @Property Syntax

graemer
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
Reply | Threaded
Open this post in threaded view
|

RE: Proposal to Improve @Property Syntax

Dierk König
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

Reply | Threaded
Open this post in threaded view
|

Re: 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
|

Re: Proposal to Improve @Property Syntax

Russel Winder
In reply to this post by graemer
On Sun, 2006-03-05 at 13:25 +0000, Graeme Rocher wrote:

> 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.

I agree that @Property is currently inconsistent with the rest of the
syntax of Groovy and unless annotations happen before 1.0 is released
would be a hook on which all the Groovy detractors and FUDsters could
hang their complaints.

From John we have:

> 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
This leaves Groovy with no way of specifying package scope unspecified
type variables.

> 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.
I am sure people doing 2 can take care of themselves :-)

1 though does seem a little more like a breakage to worry about:  we are
losing the interworkability of Java and Groovy.
 
--
Russel.
====================================================
Dr Russel Winder                +44 20 7585 2200
41 Buckmaster Road              +44 7770 465 077
London SW11 1EN, UK             [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to Improve @Property Syntax

graemer
On 07/03/06, Russel Winder <[hidden email]> wrote:

> On Sun, 2006-03-05 at 13:25 +0000, Graeme Rocher wrote:
>
> > 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.
>
> I agree that @Property is currently inconsistent with the rest of the
> syntax of Groovy and unless annotations happen before 1.0 is released
> would be a hook on which all the Groovy detractors and FUDsters could
> hang their complaints.
>
> From John we have:
>
> > 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
>
> This leaves Groovy with no way of specifying package scope unspecified
> type variables.
>
> > 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.
John, can you elaborate on why this would happen as I'm not entirely
clear why this would be a side effect.

> >
> > 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.
>
> I am sure people doing 2 can take care of themselves :-)
>
> 1 though does seem a little more like a breakage to worry about:  we are
> losing the interworkability of Java and Groovy.
>
> --
> Russel.
> ====================================================
> Dr Russel Winder                +44 20 7585 2200
> 41 Buckmaster Road              +44 7770 465 077
> London SW11 1EN, UK             [hidden email]
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQBEDZrqr2EGkixYSboRAjIrAJ0RpnBbyGzaTzyKaYr9mF0/utp4LgCfcTvv
> 6fz+NSeQFcxJVhEeI0rf3cY=
> =flKX
> -----END PGP SIGNATURE-----
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to Improve @Property Syntax

tugwilson
In reply to this post by Russel Winder

On 7 Mar 2006, at 14:38, Russel Winder wrote:

> This leaves Groovy with no way of specifying package scope unspecified
> type variables.

Indeed. I'm reasonably sanguine about that ;)

>
>> 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.
>
> I am sure people doing 2 can take care of themselves :-)
>
> 1 though does seem a little more like a breakage to worry about:  
> we are
> losing the interworkability of Java and Groovy.

The loss is temporary - if the user puts public, protected or private  
in front of the declaration in the Groovy code the beak is fixed.

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


Reply | Threaded
Open this post in threaded view
|

Re: Proposal to Improve @Property Syntax

tugwilson
In reply to this post by graemer

On 7 Mar 2006, at 14:48, Graeme Rocher wrote:

>>>
>>> 1/ calling Groovy from Java would cause the Java code to fail to
>>> compile.
> John, can you elaborate on why this would happen as I'm not entirely
> clear why this would be a side effect.

In Groovy

class G {
int x = 1
}

In Java

class J {
public void f() {
    G g = new G();
    System.out.println(g.x);
    }
}

With the change this would cause an error when compiling J (x is now  
private)

changing the Groovy from int x to public int x would fix the problem.


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


Reply | Threaded
Open this post in threaded view
|

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

Jeremy Rayner
In reply to this post by graemer
Hiya,
  The use of the annotation syntax allows us to...

1) provide a hook for future AST macros
AST macros need to look ugly as they are about
to do magic.  I know some of us want the magic
to happen without any visual clue, but I see the
damned ugly @ sign and think, hmm what's that
doing.  Oh yeah, substituting getter/setter stuff
on the AST


2) participate in the same namespace as Annotations/Classes
(i.e. Property is really just groovy.lang.Property with
the implicit import groovy.lang.* at the top)

3) ...have a well defined way of mutating the meaning slightly
of a property
e.g. @Property("foo")

4) ... compile time annotations could aid tools in showing
us where the magic is
  http://www.javalobby.org/java/forums/t17876

I think Graemes examples ( http://grails.codehaus.org/Quick+Start )
could be rewritten from...

class ApplicationDataSource {
   @Property String url = "jdbc:hsqldb:mem:testDB"
   @Property String driverClassName = "org.hsqldb.jdbcDriver"
   @Property String username = "sa"
   @Property String password = ""
}

into...
class ApplicationDataSource {
   @Property
   url = "jdbc:hsqldb:mem:testDB",
   driverClassName = "org.hsqldb.jdbcDriver",
   username = "sa",
   password = ""
}

which is nice and neat, yet still warns me "oooh look
at the magic bit attached to those variables, better
watch out for those"

I think AST macros would be of future benefit for
more than just this case, and shouldn't be excluded
at this stage.

cheers

jez
--
http://javanicus.com/blog2
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to Improve @Property Syntax

Russel Winder
In reply to this post by tugwilson
On Tue, 2006-03-07 at 14:50 +0000, John Wilson wrote:

> > This leaves Groovy with no way of specifying package scope unspecified
> > type variables.
>
> Indeed. I'm reasonably sanguine about that ;)

I have to admit, I am not.  At least not yet.

The whole point of properties is to have the Beans protocol of accessors
which was originally put in place for component building and as an
abstraction layer.

What is worrying me I guess is that in Java you have:

        class X {
                private Y y ;

                public Y getY ( ) { . . . }
                public void setY ( final Y y ) { . . . }
        }

which is almost but not quite the same as:

        class X {
                public Y y ;
        }

Now in Groovy the properties thing is such that we are trying to
implement the above but with accessors -- this seems highly inefficient.
Why not ignore accessors and just use the field directly?

> > 1 though does seem a little more like a breakage to worry about:  
> > we are
> > losing the interworkability of Java and Groovy.
>
> The loss is temporary - if the user puts public, protected or private  
> in front of the declaration in the Groovy code the beak is fixed.

Again the problem is package scope which has no keyword.
--
Russel.
====================================================
Dr Russel Winder                +44 20 7585 2200
41 Buckmaster Road              +44 7770 465 077
London SW11 1EN, UK             [hidden email]

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal to Improve @Property Syntax

tugwilson

On 7 Mar 2006, at 16:10, Russel Winder wrote:

>
> Now in Groovy the properties thing is such that we are trying to
> implement the above but with accessors -- this seems highly  
> inefficient.
> Why not ignore accessors and just use the field directly?


I think you would find it very hard to measure the difference in  
between accessing a property and accessing a field from Groovy. Both  
these operations are mediated by the MetaClass in essence they both  
require at least one method call.

In Java the Hotspot people claim that they can compile away the  
difference between property and member access.


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


1234 ... 12