7:55 a.m.
2017-03-23 16:39 GMT+01:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
It’s interesting.
How does that work when Ceylon decides to go for a native support instead of the
extraction model? Can they keep a mix?
I.e. do we prioritize the actual ConstraintViolation<Min,ceylon.language.Integer>
over a ValueExtractor<@ExtractedValue ceylon.language.Integer> +
ConstraintViolation<Min,Integer>
I see that you used @UnwrapByDefault, my concern comes from that.
Right, the extractor would be preferred. So Ceylon would have to
provide either the extractor or the dedicated constraint validator.
A related case is Java's OptionalInt, OptionalLong and OptionalDouble.
It'd be nice if all existing constraints for int/long/double would
automatically be applied to them.
Given the point in time I think though I'd rather mandate that the
built-in numeric constraints are supported for those, too, and first
explore the handling of non-generic containers in the RI. In a future
revision this requirement towards BV implementations could be changed
into mandatory value extractors for these types, without breaking user
code.
WDYT?
BTW it will mandate nested extractor support.
> On 23 Mar 2017, at 03:52, Gunnar Morling <gunnar(a)hibernate.org> wrote:
>
> Hi,
>
> I've received some very interesting feedback on the value extraction
> proposal from our team working on the Ceylon language.
>
> Ceylon does not only have its own collection framework, but also
> custom numeric wrappers, e.g. ceylon.language.Integer. Of course it'd
> be desirable to be able to apply existing constraints such as @Min to
> these. Instead of creating custom implementations such as
> ConstraintValidator<Min, ceylon.language.Integer> we thought value
> extractors could be used to enable all the existing constraints and
> validators:
>
> @UnwrapByDefault
> public class IntegerValueExtractor implements
> ValueExtractor<@ExtractedValue ceylon.language.Integer> {
>
> public void extractValues(
> ceylon.language.Integer originalValue, ValueReceiver receiver) {
>
> receiver.value( null, originalValue.getValue() );
> }
> }
>
> The problem only is that BV cannot derive the wrapped type
> (java.lang.Integer) from the annotated extracted value type
> (ceylon.language.Integer) in this case, as it isn't generic.
>
> My question is: should we support this use case? If so, how? One
> option I can see is allowing to specify the wrapped type explicitly if
> the wrapper is non-generic:
>
> public class IntegerValueExtractor implements
> ValueExtractor<(a)ExtractedValue(type=int.class)
> ceylon.language.Integer> {
> ...
> }
>
> type() would have a default value of void.class, so it doesn't have to
> be specified if the wrapped type can be derived.
>
> We also could decide to not support, requiring integrators such as
> Ceylon to declare their own constraint validators for BV built-in
> constraints, but obviously that'd fall short when it comes to
> 3rd-party custom constraints for basic Java datatypes.
>
> Thoughts?
>
> --Gunnar
> _______________________________________________
> 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