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

Hi Matt, Putting the specific spec wording aside for a moment, how would such extractor implementation make it possible to tell the wrapped type? When validating a constraint on an element of type OptionalInt, the validation engine needs to know that this "behaves as an int", so it can determine the applicable constraint validators. For something like List<@Email String> we can obtain that information from the type argument (so we know we need to look for validators on String), but it's not doable for OptionalInt which doesn't bear any hint that it is about int. Hence the idea of extending the @ExtractedValue annotation to convey that information in such case.

--Gunnar 2017-05-10 17:33 GMT+02:00 Matt Benson <mbenson(a)apache.org&gt;: > On Wed, May 10, 2017 at 9:17 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: >> 2017-05-10 3:59 GMT+02:00 Matt Benson <mbenson(a)apache.org&gt;: >>> On Tue, May 9, 2017 at 8:36 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; 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(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 >> _______________________________________________ >> 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 _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev