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

[Matt Benson]

On Wed, May 10, 2017 at 9:17 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2017-05-10 3:59 GMT+02:00 Matt Benson <mbenson at apache.org>:
>> On Tue, May 9, 2017 at 8:36 AM, Gunnar Morling <gunnar at 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).

Okay, I hadn't investigated the JavaFX APIs and hadn't realized that
e.g. StringProperty and IntegerProperty did have a generic type
parameter up their hierarchy. I still don't know that I believe the
specification is fully consistent in this regard then, because section
5.5.1 refers to these as "non-generic property types." I see that the
unwrapping for these types is intended to be fulfilled by
ValueExtractor<ObservableValue<@ExtractedValue T>>, but the
"non-generic property types" wording, to me, is suggestive of, and I
think this has been discussed, something like a ValueExtractor that:

* does *not* bear an @ExtractedValue annotation, and
* *must* be marked as @UnwrapByDefault

Then it seems an implementation would provide something like:

@UnwrapByDefault
public class OptionalIntExtractor implements ValueExtractor<OptionalInt> {
  void extractValues(OptionalInt originalValue, ValueReceiver receiver) {
    if (originalValue.isPresent()) {
      receiver.value(null, originalValue.getAsInt());
    }
  }
}

This seems so simple that perhaps I am missing something; what is it? :)

Matt

>
>>
>> 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev