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.
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