[bv-dev] On the support for Optional (was Re: Support for constraints on container values (e.g. Collection<@Email String>))
Emmanuel Bernard
emmanuel at hibernate.org
Mon Nov 21 11:27:43 EST 2016
I have the same feeling and arguments.
> On 21 Nov 2016, at 17:25, Christian Kaltepoth <christian at kaltepoth.de> wrote:
>
> Not sure I like the idea of supporting Optional<T> for return types but not for fields and method parameters. Is there any technical reason for this restriction? I agree that using Optional<T> for fields is an anti-pattern, but I don't see any reason for not supporting it nevertheless.
>
> Am I missing something here?
>
> 2016-11-21 15:18 GMT+01:00 Gunnar Morling <gunnar at hibernate.org <mailto:gunnar at hibernate.org>>:
> Yes, probably we should not support Optional for fields. Also parameters are dubious (the JDK team discourages that afaik). But supporting it for return values (and getter-based properties) seems reasonable.
>
> 2016-11-21 14:32 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org <mailto:emmanuel at hibernate.org>>:
>
>> On 7 Nov 2016, at 23:42, Hendrik Ebbers <hendrik.ebbers at me.com <mailto:hendrik.ebbers at me.com>> wrote:
>>
>> I don’t think that support for Optional is that important since having a field of type Optional looks like an anti-pattern to me. Normally Optional should be used as a method return type and not as a type for a field. Supporting it in the bean validation might end in strange model classes.
>>
>> Example:
>>
>> The following model looks good to me:
>>
>> public class Model {
>>
>> @NotNull
>> private String name;
>>
>> public String getName() { return name; }
>>
>> public void setName(String name) { this.name <http://this.name/> = name; }
>>
>> public Optional<String> name() { return Optional.ofNullable(name);}
>>
>> }
>>
>> On the other hand this looks like an anti-pattern to me:
>>
>> public class Model {
>>
>> @NotNull
>> private Optional<String> name;
>>
>> public Optional<String> getName() { return name; }
>>
>> public void setName(String name) { this.name <http://this.name/> = Optional.ofNullable(name); }
>>
>> }
>
> Yes Optional on a property is deemed an anti pattern by the JDK team but since Bean Validation supports contraints on method parameters and return values, this is still a valid use case
>
> Optional<@Email String> getUserEmail(@NotNull UUID userId);
>
> Emmanuel
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org <mailto:beanvalidation-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev <https://lists.jboss.org/mailman/listinfo/beanvalidation-dev>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org <mailto:beanvalidation-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev <https://lists.jboss.org/mailman/listinfo/beanvalidation-dev>
>
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/ <http://blog.kaltepoth.de/>
> Twitter: http://twitter.com/chkal <http://twitter.com/chkal>
> GitHub: https://github.com/chkal <https://github.com/chkal>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20161121/f9ee74e2/attachment.html
More information about the beanvalidation-dev
mailing list