Re: [bv-dev] Support for OptionalInt, OptionalLong and OptionalDouble
2017-05-10 3:59 GMT+02:00 Matt Benson <mbenson(a)apache.org>:
On Tue, May 9, 2017 at 8:36 AM, Gunnar Morling
<gunnar(a)hibernate.org> wrote:
> Hi,
>
> I'm curious about your take on supporting the types in ${subject}
> (BVAL-579 [1]).
>
> They are non-generic wrappers for int, long and double. Should we
> support them with the numeric constraints such as @Min et al.? The
> easiest way to do so would be to just mandate support in the JavaDoc
> of the numeric constraint types.
>
> The only thing I can see speaking against this is that we may migrate
> to an extractor-based approach in a future revision. Currently
> extractors cannot be used, as those types don't have any type
> parameter which could be extracted. But assuming we extend the
> extractor API in a future revision to deal with non-generic types,
> too, we could then rather mandate built-in extractors for those types.
> Which will allow to put *any* constraint applying to int also to
> OptionalInt.
Wait... the current draft of the spec still mentions implicit
unwrapping of containers. Is that not staying? Why can't we have e.g.
an extractor of OptionalInt to Integer, returning an absent value as
null?
Implicit unwrapping is staying, but value extraction cannot be used as
is, as we'd lack a way for obtaining the wrapped type from a value
extractor for a non-generic type:
OptionalIntExtractor implements ValueExtractor<@ExtractedValue
OptionalInt> {
}
There is no type parameter/argument from which the wrapped type (int)
could be obtained (which is needed for finding the right constraint
validator). We could add an attribute to @ExtractedValue for such
cases: @ExtractedValue(wrappedType=int.class).
We could do this in a future revision or if we are confident about it
in the Proposed Final draft. We are going to explore it in the RI (by
using a separate annotation next to @ExtractedValue for the time
being).
Matt
>
> Should we do such change in a future revision, I don't think anything
> would change for users. Only providers would have to implement support
> for these types via extractors instead of dedicated constraint
> validators. I think such change is acceptable.
>
> What do others think?
>
> Thanks,
>
> --Gunnar
>
> [1] https://hibernate.atlassian.net/browse/BVAL-579
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev