5:52 a.m.
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
10:39 a.m.
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
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
2773
days inactive
2802
days old
beanvalidation-dev@lists.jboss.org
2 comments
2 participants
participants (2)
-
Emmanuel Bernard -
Gunnar Morling