@Immutable and "deemed" Immutable classes

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

@Immutable and "deemed" Immutable classes

Andre Steingress
Hi,

I need your feedback concerning https://jira.codehaus.org/browse/GROOVY-5096

The issue is about providing a mechanism to tell @Immutable that certain types are immutable although not immutable in terms of the ImmutableASTTransformation rules.

My suggestion would be to introduce an inner annotation type to @Immutable:

public @interface Immutable {

    @Retention(RetentionPolicy.RUNTIME)
    @Target({ElementType.FIELD})
    static public @interface Ignore {}

}

Thus data types being known as immutable could be annotated with:

@Immutable class Person {      
      @Immutable.Ignore MyType test
}

Any suggestions on how to specify those "deemed" immutable classes? Should we better provides a separate annotation or an annotation holding an array of these classes?

Cheers, André
Reply | Threaded
Open this post in threaded view
|

Re: @Immutable and "deemed" Immutable classes

Cédric Champeau
Hi,

I would prefer the annotation holding an array of classes to be ignored.
I see two advantages:
     * no annotation inner class (which is the first time I see this :))
     * avoids "polluting" the code with multiple annotations when you
have, for example, multiple fields with the same type

Still, we need to discuss the pros and cons of each solution.

Le 17/02/2012 10:30, Andre Steingress a écrit :

> Hi,
>
> I need your feedback concerning https://jira.codehaus.org/browse/GROOVY-5096
>
> The issue is about providing a mechanism to tell @Immutable that certain
> types are immutable although not immutable in terms of the
> ImmutableASTTransformation rules.
>
> My suggestion would be to introduce an inner annotation type to @Immutable:
>
> public @interface Immutable {
>
>      @Retention(RetentionPolicy.RUNTIME)
>      @Target({ElementType.FIELD})
>      static public @interface Ignore {}
>
> }
>
> Thus data types being known as immutable could be annotated with:
>
> @Immutable class Person {
>        @Immutable.Ignore MyType test
> }
>
> Any suggestions on how to specify those "deemed" immutable classes? Should
> we better provides a separate annotation or an annotation holding an array
> of these classes?
>
> Cheers, André
>
> --
> View this message in context: http://groovy.329449.n5.nabble.com/Immutable-and-deemed-Immutable-classes-tp5491964p5491964.html
> Sent from the groovy - dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>      http://xircles.codehaus.org/manage_email
>
>
>


--
Cédric Champeau
SpringSource - A Division Of VMware
http://www.springsource.com/
http://twitter.com/CedricChampeau


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: @Immutable and "deemed" Immutable classes

Andre Steingress
Cédric Champeau wrote
I would prefer the annotation holding an array of classes to be ignored.
I see two advantages:
     * no annotation inner class (which is the first time I see this :))
     * avoids "polluting" the code with multiple annotations when you
have, for example, multiple fields with the same type
nested annotations are kind of freaky :-)

The question is whether to allow the specification of implicit immutable properties on a field-level or class-level basis. On a field-level basis, another option would be to provide a property exclusion list as it is done with @ToString:

@Immutable(ignore='x,y') class A {
     
      SomeImmutableType x
      SomeImmutableType y

}



Cheers, André
Reply | Threaded
Open this post in threaded view
|

Re: @Immutable and "deemed" Immutable classes

Cédric Champeau
If the problem is that some fields are known immutables, then I think it
makes more sense to be based on a class level, rather than field level,
because like in your example, two fields may have the same type, and it
wouldn't make sense to have one marked as immutable, and the other not.

Le 17/02/2012 11:50, Andre Steingress a écrit :

> Cédric Champeau wrote
>> I would prefer the annotation holding an array of classes to be ignored.
>> I see two advantages:
>>       * no annotation inner class (which is the first time I see this :))
>>       * avoids "polluting" the code with multiple annotations when you
>> have, for example, multiple fields with the same type
>>
> nested annotations are kind of freaky :-)
>
> The question is whether to allow the specification of implicit immutable
> properties on a field-level or class-level basis. On a field-level basis,
> another option would be to provide a property exclusion list as it is done
> with @ToString:
>
> @Immutable(ignore='x,y') class A {
>
>        SomeImmutableType x
>        SomeImmutableType y
>
> }
>
>
>
> Cheers, André
>
> --
> View this message in context: http://groovy.329449.n5.nabble.com/Immutable-and-deemed-Immutable-classes-tp5491964p5492130.html
> Sent from the groovy - dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>      http://xircles.codehaus.org/manage_email
>
>
>


--
Cédric Champeau
SpringSource - A Division Of VMware
http://www.springsource.com/
http://twitter.com/CedricChampeau


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: @Immutable and "deemed" Immutable classes

aalmiray
String parameters are not "type safe" yadda yadda yadda ;-)

I'd rather pick a Class than a String; also following Cedric's train of thought, no need to specify two fields if they share the same type as it's the type you want to define as immutable, not the names ;-)
Reply | Threaded
Open this post in threaded view
|

Re: @Immutable and "deemed" Immutable classes

Travis Schneeberger
I'm sortof thinking out loud so forgive me....

It's true the type normally defines immutability but there are several places where different fields of the same type might want to be targeted individually

1) if a field is derived from other fields.  Sometimes these fields aren't needed to be defensively copied and may not even be a part of the equals/hashcode/toString implementation.

2) data structures can be immutable but this depends on what the data structure contains.  So going by the type of the structure doesn't make sense in all cases.

Not sure if we want to make these distinctions but I thought it was worth mentioning.

~Travis

On Fri, Feb 17, 2012 at 8:45 AM, aalmiray <[hidden email]> wrote:
String parameters are not "type safe" yadda yadda yadda ;-)

I'd rather pick a Class than a String; also following Cedric's train of
thought, no need to specify two fields if they share the same type as it's
the type you want to define as immutable, not the names ;-)

--
View this message in context: http://groovy.329449.n5.nabble.com/Immutable-and-deemed-Immutable-classes-tp5491964p5493533.html
Sent from the groovy - dev mailing list archive at Nabble.com.

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

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: @Immutable and "deemed" Immutable classes

Andre Steingress
In reply to this post by Cédric Champeau
Yes, you're right - in case of my artificial code sample it doesn't make sense.

My thought was there could be circumstances where you do not have the information to decide on what types to exclude, or need a property-level granularity. e.g. a class relies on Spring constructor injection and uses a dynamically typed service bean, whereas this bean does not interfer with the objects immutability. For example consider this Spring bean:

class Message {
     String text
     String subject  
     MessageReceiver receiver

     transient bodyConverterService

     String getConvertedText()  { bodyConverterService.convert(....) }      
}

Message beans would be completely immutable. The only property which is implicitly immutable as it is stateless would be the bodyConverterService singleton of static type 'java.lang.Object'. Currently, message objects couldn't be @Immutable although they only reference a Spring bean which does not interfere with immutability at all.

Maybe this is an edge case we shouldn't care about in the first run, but that was my train of thought :) but yay, I'm in for the class array:

@Immutable(knownImmutables = [SomeImmutableType]) class A {
    SomeImmutableType x
    SomeImmutableType y
}

Cheers, André
Reply | Threaded
Open this post in threaded view
|

Re: @Immutable and "deemed" Immutable classes

paulk_asert

+1 for the class array.

On 18/02/2012 7:12 AM, Andre Steingress wrote:

> Yes, you're right - in case of my artificial code sample it doesn't make
> sense.
>
> My thought was there could be circumstances where you do not have the
> information to decide on what types to exclude, or need a property-level
> granularity. e.g. a class relies on Spring constructor injection and uses a
> dynamically typed service bean, whereas this bean does not interfer with the
> objects immutability. For example consider this Spring bean:
>
> class Message {
>       String text
>       String subject
>       MessageReceiver receiver
>
>       transient bodyConverterService
>
>       String getConvertedText()  { bodyConverterService.convert(....) }
> }
>
> Message beans would be completely immutable. The only property which is
> implicitly immutable as it is stateless would be the bodyConverterService
> singleton of static type 'java.lang.Object'. Currently, message objects
> couldn't be @Immutable although they only reference a Spring bean which does
> not interfere with immutability at all.
>
> Maybe this is an edge case we shouldn't care about in the first run, but
> that was my train of thought :) but yay, I'm in for the class array:
>
> @Immutable(knownImmutables = [SomeImmutableType]) class A {
>      SomeImmutableType x
>      SomeImmutableType y
> }
>
> Cheers, André
>
>
> --
> View this message in context: http://groovy.329449.n5.nabble.com/Immutable-and-deemed-Immutable-classes-tp5491964p5494012.html
> Sent from the groovy - dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> 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