[bv-dev] Support for OptionalInt, OptionalLong and OptionalDouble

[Guillaume Smet]

Hi,

On Wed, May 17, 2017 at 3:33 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> >
> > * Should we be really brave and rename or alias that member to value()?
>
> I thought about it, but value() reads poorly if other members are
> added down the road (I cannot think of any, though). But given that
> @ExtractedValue is only used by BV providers and a very few authors of
> custom extractors, I don't mind the few extra characters of type() for
> the sake of more explicitness.
>
> What do others think?
>

I don't think using value is a good idea. It might be clear now but won't
be if we decide to add another attribute later.


>
> > * Should we permit to specify as int.class and force the implementation
> to
> > wrap? (I haven't tried it, and also haven't been awake very long, but I
> > can't think why it wouldn't work)
>
> Would there be any advantage to that? During constraint validator
> resolution (where this ends up being used), "primitive types are
> considered equivalent to their respective primitive wrapper class", so
> it shouldn't make a difference.
>

As for OptionalInt, I first used int.class for the ValueExtractor in HV but
then realized that the extracted type is indeed Integer.class as we extract
a null value if the value is not present.

In any case, HV boxes the primitive types automatically as HV only deals
with boxed types but this part is implementation specific.

-- 
Guillaume
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170517/f4cca150/attachment.html