[jira] [Commented] (GROOVY-6555) Allow @Immutable classes to validate their properties upon construction

["Nick Stokoe (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GROOVY-6555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15177902#comment-15177902 ] 

Nick Stokoe commented on GROOVY-6555:
-------------------------------------

Validate... or transform.  My use case: a user class whose log-in is case insensitive, I want to transparently down-case the log-in parameter passed before it is assigned.

> Allow @Immutable classes to validate their properties upon construction
> -----------------------------------------------------------------------
>
>                 Key: GROOVY-6555
>                 URL: https://issues.apache.org/jira/browse/GROOVY-6555
>             Project: Groovy
>          Issue Type: Improvement
>          Components: ast builder
>            Reporter: Jan Bols
>
> Currently classes annotated with @Immutable are not allowed to create their own constructor. Instead a map-based and an ordered-based constructor is added by the {{ImmutableASTTransformation}}
> However it would be great if there was some way to *validate* the arguments that are used to populate the immatable object. This would allow the developer to use @Immutable to build [value objects|http://martinfowler.com/bliki/ValueObject.html] allowing them to assert that certain properties are set, certain properties have a certain value, etc...
> A way of implementing this improvement that I can think of is to allow the developer to create his own constructor, relying on the skills of the developer to keep the object immutable
> Another way would be to allow the developer to specify an 'afterPropertiesSet' method in the @Immutable annotation f.e.
> {code:java}
> @Immutable(validationMethod="afterPropertiesSet")
> class MyClass{
>   private afterPropertiesSet(){
>   //some validation of the fields that have been set in the constructor
>   }
> }
> {code}
> This method would be called in the constructors as the last statement.
> Perhaps other solutions exist as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)