groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <>
Subject Re: Making @Immutable a meta-annotation
Date Sat, 13 Jan 2018 03:43:36 GMT
Hi Paul,

I think the core of the problem is, that @Immutable as a meta-annotation 
woud be better off being called something along the line of 
@ImmutableCanonical (see: If you do no need the immutability, use 
@Canonical), since it does not solely supply immutability support - then 
it would be natural to call the actual core immutability annotation just 

That is probably off the table, since it would be a breaking change - so 
we are stuck with the problem of naming the immutability annotation part 
something else.

@ImmutableClass would imply to me that the "Class" part carries some 
meaning, which I feel it does not, since
a) "Class" could be postfixed to any annotation name that applies to classes
b) The meta-annotation should accordingly also be called "ImmutableClass"
Because of that I find postfixing "Immutable" with "Class" just 
confusing. It also is not intuitive to me, which annotation does only 
supply the core, and which supplies the extended (canonical) 

I do not understand where you are going with @KnownImmutable (known to 
whom ?-) To me this seems less intuitive/more confusing than 

@ImmutableCore is similar to @ImmutableBase (because I intentionally 
based it on it :-) ), but different in the sense that it imho expresses 
the semantics of the annotation: Making the object purely 
immutable-only, without any constructors, toString functionality, etc.

How about:







On 12.01.2018 08:01, Paul King wrote:
> @ImmutableCore is similar to @ImmutableBase - probably okay but I 
> don't think ideal. Another alternative would be @ImmutableInfo or have 
> an explicit marker interface with a different package, e.g. 
> groovy.transform.marker.Immutable but that might cause IDE completion 
> headaches. Perhaps @KnownImmutable as a straight marker interface 
> might be the way to go - then it could be used explicitly on manually 
> created immutable classes and avoid the need to use the 
> knownImmutableClasses/knownImmutables annotation attributes for that 
> case.
> Cheers, Paul.
> On Thu, Jan 11, 2018 at 9:34 PM, mg < 
> <>> wrote:
>     Hi Paul,
>     great to make @Immutable more fine granular / flexible :-)
>     what about
>     @ImmutabilityChecked
>     or
>     @ImmutableCore
>     instead of @ImmutableClass ?
>     Cheers
>     mg
>     -------- Urspr√ľngliche Nachricht --------
>     Von: Paul King < <>>
>     Datum: 11.01.18 08:07 (GMT+01:00)
>     An: <>
>     Betreff: Making @Immutable a meta-annotation
>     There has been discussion on and off about making @Immutable a
>     meta-annotation (annotation collector) in much the same way as
>     @Canonical was re-vamped. (This is for 2.5+).
>     I have a preliminary PR which does this:
>     <>
>     Preliminary because it still needs a bit of refactoring to reduce
>     some duplication of code that exists between the normal and
>     immutable map and tuple constructors. I still need to do this but
>     that can happen transparently behind the scenes as an
>     implementation detail if we don't finish it straight away. As well
>     as reducing duplication, the pending refactoring will enable
>     things like the pre and post options for MapConstructor and
>     TupleConstructor which aren't currently working.
>     I am keen on any feedback at this point. In particular, while most
>     of the functionality is pushed off into the collected
>     annotations/transforms, I ended up with some left over checks
>     which I kept in an annotation currently called @ImmutableClass. I
>     tried various names for this class, e.g. @ImmutableBase and
>     @ImmutableCheck but finally settled on @ImmutableClass since the
>     annotation causes the preliminary checks to be performed but also
>     acts as a marker interface for the MapConstructor and
>     TupleConstructor transforms to do the alternate code needed for
>     immutability and to indicate that a class is immutable when it
>     might itself be a property of another immutable class. Let me know
>     if you can think of a better name or have any other feedback.
>     Cheers, Paul.

View raw message