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
"Immutable".
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)
functionality...
I do not understand where you are going with @KnownImmutable (known to
whom ?-) To me this seems less intuitive/more confusing than
@ImmutableClass...).
@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:
@ImmutableOnly
@PureImmutable
@ModificationProtected
@Locked
@Frozen
@Unchangeable
@Changeless
@InitOnly
@InitializeOnly
@Constant
@Const
@NonModifieable
@NonChangeable
?
mg
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 <mg...@arscreat.com
<mailto:mg...@arscreat.com>> 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 <pa...@asert.com.au <mailto:pa...@asert.com.au>>
Datum: 11.01.18 08:07 (GMT+01:00)
An: dev@groovy.apache.org <mailto:dev@groovy.apache.org>
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:
https://github.com/apache/groovy/pull/653
<https://github.com/apache/groovy/pull/653>
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.
