sticky properties

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
12
Reply | Threaded
Open this post in threaded view
|

sticky properties

John Sanda-3
Has any consideration been given to adding an annotation for "sticky"
properties? By sticky, I mean like properties in Ant in that once set,
you cannot change the value. I'm sure that there are plenty of reasons
for/against this. I'm just curious about it. I think it would be a
nice addition to an already awesome language.

--

- John

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: sticky properties

Guillaume Laforge
Administrator
On 6/30/06, John Sanda <[hidden email]> wrote:
> Has any consideration been given to adding an annotation for "sticky"
> properties? By sticky, I mean like properties in Ant in that once set,
> you cannot change the value. I'm sure that there are plenty of reasons
> for/against this. I'm just curious about it. I think it would be a
> nice addition to an already awesome language.

Making your properties "final" should have the desired effect.
And thanks for the kind words ;-)

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

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: sticky properties

John Sanda-3
I wasn't very clear in my previous email. Making a property final
doesn't provide the behavior I am looking for. Let me illustrate with
the following example.

class Foo {
   @Property(sticky="true") bar
}

Suppose the Property annotation accepted an attribute named sticky
that when set to true resulted in something like the following code
being generated.

void setBar(bar) {
   if (bar == null) {
      this.bar = bar
   }
}

Or a preferable approach IMO would be to set the property in the
constructor and have a property mutator like the following generated.

void setBar(bar) {
}

Last week I was writing a custom Ant task (in Groovy), and I really
liked being able to use the concise object initialization that Groovy
provides with the map syntax (e.g., new MyObject(prop1:val1,
prop2:val2). I had a couple situations in which I wanted to make a
property "sticky" as I described above. The code I have to write to
make a property "sticky" is pretty boiler-plate, and I hate to
duplicate it across classes.

If I was trying to achieve this in Java, AOP + annotations would be an
elegant solution. Maybe there already is a way to do this in Groovy
with AOP or otherwise. I am just not aware.

On 7/2/06, Guillaume Laforge <[hidden email]> wrote:

> On 6/30/06, John Sanda <[hidden email]> wrote:
> > Has any consideration been given to adding an annotation for "sticky"
> > properties? By sticky, I mean like properties in Ant in that once set,
> > you cannot change the value. I'm sure that there are plenty of reasons
> > for/against this. I'm just curious about it. I think it would be a
> > nice addition to an already awesome language.
>
> Making your properties "final" should have the desired effect.
> And thanks for the kind words ;-)
>
> --
> Guillaume Laforge
> Groovy Project Manager
> http://glaforge.free.fr/blog/groovy
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--

- John

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: sticky properties

graemer
hmm I still believe that final solves your problem as Guillaume said. doing:

final bar

Will generate a getter but not a setter. Under what circumstance would
you want to set something that can't be set? It is for all intents an
purposes read-only. If you need an intial value you can do:

final bar = 1

The "bar" property can then never be changed for the life time of thhe
object. How does this not solve your problem?

Graeme

On 7/3/06, John Sanda <[hidden email]> wrote:

> I wasn't very clear in my previous email. Making a property final
> doesn't provide the behavior I am looking for. Let me illustrate with
> the following example.
>
> class Foo {
>    @Property(sticky="true") bar
> }
>
> Suppose the Property annotation accepted an attribute named sticky
> that when set to true resulted in something like the following code
> being generated.
>
> void setBar(bar) {
>    if (bar == null) {
>       this.bar = bar
>    }
> }
>
> Or a preferable approach IMO would be to set the property in the
> constructor and have a property mutator like the following generated.
>
> void setBar(bar) {
> }
>
> Last week I was writing a custom Ant task (in Groovy), and I really
> liked being able to use the concise object initialization that Groovy
> provides with the map syntax (e.g., new MyObject(prop1:val1,
> prop2:val2). I had a couple situations in which I wanted to make a
> property "sticky" as I described above. The code I have to write to
> make a property "sticky" is pretty boiler-plate, and I hate to
> duplicate it across classes.
>
> If I was trying to achieve this in Java, AOP + annotations would be an
> elegant solution. Maybe there already is a way to do this in Groovy
> with AOP or otherwise. I am just not aware.
>
> On 7/2/06, Guillaume Laforge <[hidden email]> wrote:
> > On 6/30/06, John Sanda <[hidden email]> wrote:
> > > Has any consideration been given to adding an annotation for "sticky"
> > > properties? By sticky, I mean like properties in Ant in that once set,
> > > you cannot change the value. I'm sure that there are plenty of reasons
> > > for/against this. I'm just curious about it. I think it would be a
> > > nice addition to an already awesome language.
> >
> > Making your properties "final" should have the desired effect.
> > And thanks for the kind words ;-)
> >
> > --
> > Guillaume Laforge
> > Groovy Project Manager
> > http://glaforge.free.fr/blog/groovy
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>
>
> --
>
> - John
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: sticky properties

John Sanda-3
The problem is that if I want to assign a final variable a value, I
must do so at the point of declaration. So, I can't do this:

final bar
...
bar = 1

As I mentioned previously, the use case for this came up in writing a
custom ant task, in which these "sticky" properties are central to
Ant. Maybe the use cases aren't there outside of Ant.

On 7/3/06, Graeme Rocher <[hidden email]> wrote:

> hmm I still believe that final solves your problem as Guillaume said. doing:
>
> final bar
>
> Will generate a getter but not a setter. Under what circumstance would
> you want to set something that can't be set? It is for all intents an
> purposes read-only. If you need an intial value you can do:
>
> final bar = 1
>
> The "bar" property can then never be changed for the life time of thhe
> object. How does this not solve your problem?
>
> Graeme
>
> On 7/3/06, John Sanda <[hidden email]> wrote:
> > I wasn't very clear in my previous email. Making a property final
> > doesn't provide the behavior I am looking for. Let me illustrate with
> > the following example.
> >
> > class Foo {
> >    @Property(sticky="true") bar
> > }
> >
> > Suppose the Property annotation accepted an attribute named sticky
> > that when set to true resulted in something like the following code
> > being generated.
> >
> > void setBar(bar) {
> >    if (bar == null) {
> >       this.bar = bar
> >    }
> > }
> >
> > Or a preferable approach IMO would be to set the property in the
> > constructor and have a property mutator like the following generated.
> >
> > void setBar(bar) {
> > }
> >
> > Last week I was writing a custom Ant task (in Groovy), and I really
> > liked being able to use the concise object initialization that Groovy
> > provides with the map syntax (e.g., new MyObject(prop1:val1,
> > prop2:val2). I had a couple situations in which I wanted to make a
> > property "sticky" as I described above. The code I have to write to
> > make a property "sticky" is pretty boiler-plate, and I hate to
> > duplicate it across classes.
> >
> > If I was trying to achieve this in Java, AOP + annotations would be an
> > elegant solution. Maybe there already is a way to do this in Groovy
> > with AOP or otherwise. I am just not aware.
> >
> > On 7/2/06, Guillaume Laforge <[hidden email]> wrote:
> > > On 6/30/06, John Sanda <[hidden email]> wrote:
> > > > Has any consideration been given to adding an annotation for "sticky"
> > > > properties? By sticky, I mean like properties in Ant in that once set,
> > > > you cannot change the value. I'm sure that there are plenty of reasons
> > > > for/against this. I'm just curious about it. I think it would be a
> > > > nice addition to an already awesome language.
> > >
> > > Making your properties "final" should have the desired effect.
> > > And thanks for the kind words ;-)
> > >
> > > --
> > > Guillaume Laforge
> > > Groovy Project Manager
> > > http://glaforge.free.fr/blog/groovy
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe from this list please visit:
> > >
> > >     http://xircles.codehaus.org/manage_email
> > >
> > >
> >
> >
> > --
> >
> > - John
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--

- John

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: sticky properties

graemer
On 7/3/06, John Sanda <[hidden email]> wrote:
> The problem is that if I want to assign a final variable a value, I
> must do so at the point of declaration. So, I can't do this:
>
> final bar
> ...
> bar = 1

Not necessarily you can set the value of a final field with both java
and groovy inside the constructor of the object.

Graeme

>
> As I mentioned previously, the use case for this came up in writing a
> custom ant task, in which these "sticky" properties are central to
> Ant. Maybe the use cases aren't there outside of Ant.
>
> On 7/3/06, Graeme Rocher <[hidden email]> wrote:
> > hmm I still believe that final solves your problem as Guillaume said. doing:
> >
> > final bar
> >
> > Will generate a getter but not a setter. Under what circumstance would
> > you want to set something that can't be set? It is for all intents an
> > purposes read-only. If you need an intial value you can do:
> >
> > final bar = 1
> >
> > The "bar" property can then never be changed for the life time of thhe
> > object. How does this not solve your problem?
> >
> > Graeme
> >
> > On 7/3/06, John Sanda <[hidden email]> wrote:
> > > I wasn't very clear in my previous email. Making a property final
> > > doesn't provide the behavior I am looking for. Let me illustrate with
> > > the following example.
> > >
> > > class Foo {
> > >    @Property(sticky="true") bar
> > > }
> > >
> > > Suppose the Property annotation accepted an attribute named sticky
> > > that when set to true resulted in something like the following code
> > > being generated.
> > >
> > > void setBar(bar) {
> > >    if (bar == null) {
> > >       this.bar = bar
> > >    }
> > > }
> > >
> > > Or a preferable approach IMO would be to set the property in the
> > > constructor and have a property mutator like the following generated.
> > >
> > > void setBar(bar) {
> > > }
> > >
> > > Last week I was writing a custom Ant task (in Groovy), and I really
> > > liked being able to use the concise object initialization that Groovy
> > > provides with the map syntax (e.g., new MyObject(prop1:val1,
> > > prop2:val2). I had a couple situations in which I wanted to make a
> > > property "sticky" as I described above. The code I have to write to
> > > make a property "sticky" is pretty boiler-plate, and I hate to
> > > duplicate it across classes.
> > >
> > > If I was trying to achieve this in Java, AOP + annotations would be an
> > > elegant solution. Maybe there already is a way to do this in Groovy
> > > with AOP or otherwise. I am just not aware.
> > >
> > > On 7/2/06, Guillaume Laforge <[hidden email]> wrote:
> > > > On 6/30/06, John Sanda <[hidden email]> wrote:
> > > > > Has any consideration been given to adding an annotation for "sticky"
> > > > > properties? By sticky, I mean like properties in Ant in that once set,
> > > > > you cannot change the value. I'm sure that there are plenty of reasons
> > > > > for/against this. I'm just curious about it. I think it would be a
> > > > > nice addition to an already awesome language.
> > > >
> > > > Making your properties "final" should have the desired effect.
> > > > And thanks for the kind words ;-)
> > > >
> > > > --
> > > > Guillaume Laforge
> > > > Groovy Project Manager
> > > > http://glaforge.free.fr/blog/groovy
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe from this list please visit:
> > > >
> > > >     http://xircles.codehaus.org/manage_email
> > > >
> > > >
> > >
> > >
> > > --
> > >
> > > - John
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe from this list please visit:
> > >
> > >     http://xircles.codehaus.org/manage_email
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>
>
> --
>
> - John
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: sticky properties

Jochen Theodorou
In reply to this post by John Sanda-3
John Sanda schrieb:

> The problem is that if I want to assign a final variable a value, I
> must do so at the point of declaration. So, I can't do this:
>
> final bar
> ...
> bar = 1
>
> As I mentioned previously, the use case for this came up in writing a
> custom ant task, in which these "sticky" properties are central to
> Ant. Maybe the use cases aren't there outside of Ant.

hm...

class Foo {
   void setProperty(String name,Object value) {
      if(getProperty(name)!=null) return
      metaClass.setProperty(this, name, value)
   }
}

this code peace works for all proeprties of the current class, but if
you want to exclude some, you have to change the method and test the
name argument. If you have only a few sticky properties it is best to
test for them instead of excluding the others.

Of course this works only when used from Groovy and only as long as the
field is not set directly instead of using the property mechanism.

bye blackdrag

--
Jochen Theodorou
Groovy Tech Lead

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: sticky properties

John Sanda-3
In reply to this post by graemer
I am somewhat embarassed that I completely forgot that you can assign
a value to a final field inside a constructor. Thanks to both of you
for the refresher on final fields ;-) Is there still a way for me to
both initialize properties with the map syntax and my final field in
the constructor without having to write my own?

On 7/3/06, Graeme Rocher <[hidden email]> wrote:

> On 7/3/06, John Sanda <[hidden email]> wrote:
> > The problem is that if I want to assign a final variable a value, I
> > must do so at the point of declaration. So, I can't do this:
> >
> > final bar
> > ...
> > bar = 1
>
> Not necessarily you can set the value of a final field with both java
> and groovy inside the constructor of the object.
>
> Graeme
>
> >
> > As I mentioned previously, the use case for this came up in writing a
> > custom ant task, in which these "sticky" properties are central to
> > Ant. Maybe the use cases aren't there outside of Ant.
> >
> > On 7/3/06, Graeme Rocher <[hidden email]> wrote:
> > > hmm I still believe that final solves your problem as Guillaume said. doing:
> > >
> > > final bar
> > >
> > > Will generate a getter but not a setter. Under what circumstance would
> > > you want to set something that can't be set? It is for all intents an
> > > purposes read-only. If you need an intial value you can do:
> > >
> > > final bar = 1
> > >
> > > The "bar" property can then never be changed for the life time of thhe
> > > object. How does this not solve your problem?
> > >
> > > Graeme
> > >
> > > On 7/3/06, John Sanda <[hidden email]> wrote:
> > > > I wasn't very clear in my previous email. Making a property final
> > > > doesn't provide the behavior I am looking for. Let me illustrate with
> > > > the following example.
> > > >
> > > > class Foo {
> > > >    @Property(sticky="true") bar
> > > > }
> > > >
> > > > Suppose the Property annotation accepted an attribute named sticky
> > > > that when set to true resulted in something like the following code
> > > > being generated.
> > > >
> > > > void setBar(bar) {
> > > >    if (bar == null) {
> > > >       this.bar = bar
> > > >    }
> > > > }
> > > >
> > > > Or a preferable approach IMO would be to set the property in the
> > > > constructor and have a property mutator like the following generated.
> > > >
> > > > void setBar(bar) {
> > > > }
> > > >
> > > > Last week I was writing a custom Ant task (in Groovy), and I really
> > > > liked being able to use the concise object initialization that Groovy
> > > > provides with the map syntax (e.g., new MyObject(prop1:val1,
> > > > prop2:val2). I had a couple situations in which I wanted to make a
> > > > property "sticky" as I described above. The code I have to write to
> > > > make a property "sticky" is pretty boiler-plate, and I hate to
> > > > duplicate it across classes.
> > > >
> > > > If I was trying to achieve this in Java, AOP + annotations would be an
> > > > elegant solution. Maybe there already is a way to do this in Groovy
> > > > with AOP or otherwise. I am just not aware.
> > > >
> > > > On 7/2/06, Guillaume Laforge <[hidden email]> wrote:
> > > > > On 6/30/06, John Sanda <[hidden email]> wrote:
> > > > > > Has any consideration been given to adding an annotation for "sticky"
> > > > > > properties? By sticky, I mean like properties in Ant in that once set,
> > > > > > you cannot change the value. I'm sure that there are plenty of reasons
> > > > > > for/against this. I'm just curious about it. I think it would be a
> > > > > > nice addition to an already awesome language.
> > > > >
> > > > > Making your properties "final" should have the desired effect.
> > > > > And thanks for the kind words ;-)
> > > > >
> > > > > --
> > > > > Guillaume Laforge
> > > > > Groovy Project Manager
> > > > > http://glaforge.free.fr/blog/groovy
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe from this list please visit:
> > > > >
> > > > >     http://xircles.codehaus.org/manage_email
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > - John
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe from this list please visit:
> > > >
> > > >     http://xircles.codehaus.org/manage_email
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe from this list please visit:
> > >
> > >     http://xircles.codehaus.org/manage_email
> > >
> > >
> >
> >
> > --
> >
> > - John
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list please visit:
> >
> >     http://xircles.codehaus.org/manage_email
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--

- John

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: sticky properties

Alasdair-2
In reply to this post by John Sanda-3
John Sanda <john.sanda@...> writes:

>
> Has any consideration been given to adding an annotation for "sticky"
> properties? By sticky, I mean like properties in Ant in that once set,
> you cannot change the value. I'm sure that there are plenty of reasons
> for/against this. I'm just curious about it. I think it would be a
> nice addition to an already awesome language.
>
The thread has discussed properties of classes. Whilst playing with groovy I
found the following unexpected result.

Simple script:

println "Hello World"

final foo = "Foo is final"
println foo

foo = "Yet foo has changed"
println foo

results in:

Hello World
Foo is final
Yet foo has changed

I.e. I can declare a variable "final" but it doesn't seem to have any effect -
might be worth considering what the desired bahaviour is...

(apologies if this should be on the user list).


---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

Reply | Threaded
Open this post in threaded view
|

Re: sticky properties

John Sanda-3
From groovysh, I executed the following statements:

def final foo = 'final'
println foo
foo = 'not final'
println foo
go

// output...
final
not final

I never noticed this before. Does final in Groovy behave dfiferently
than it does in Java?

On 7/5/06, Alasdair <[hidden email]> wrote:

> John Sanda <john.sanda@...> writes:
>
> >
> > Has any consideration been given to adding an annotation for "sticky"
> > properties? By sticky, I mean like properties in Ant in that once set,
> > you cannot change the value. I'm sure that there are plenty of reasons
> > for/against this. I'm just curious about it. I think it would be a
> > nice addition to an already awesome language.
> >
> The thread has discussed properties of classes. Whilst playing with groovy I
> found the following unexpected result.
>
> Simple script:
>
> println "Hello World"
>
> final foo = "Foo is final"
> println foo
>
> foo = "Yet foo has changed"
> println foo
>
> results in:
>
> Hello World
> Foo is final
> Yet foo has changed
>
> I.e. I can declare a variable "final" but it doesn't seem to have any effect -
> might be worth considering what the desired bahaviour is...
>
> (apologies if this should be on the user list).
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>


--

- John

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

12