On Fri, Jan 13, 2017 at 10:23 AM, Matt Benson <mbenson@apache.org> wrote:

On Fri, Jan 13, 2017 at 8:57 AM, Emmanuel Bernard <emmanuel@hibernate.org> wrote:
s/other/order from the JVM/

> On 13 Jan 2017, at 15:54, Emmanuel Bernard <emmanuel@hibernate.org> wrote:
>
> I looked at that, and I’m not sure you are guaranteed to get an other.
> Plus you have this problem
>
> @Min
> @Min.List({@Min, @Min})
> @Min
> BooYahh foo;
>

I would have thought the same; however per [1] order is guaranteed. Your additional concern is still there. Maybe it would be cleaner to support this using meta-constraint annotations.

Actually, per the same section of the JLS, your example is referred to as "obtuse" (which I'm sure was the point you were making) would generate a compile error. So we could perhaps support Gunnar's approach after all. A meta-annotation might look cleaner, but it might become painful to define a lot of these.

Matt
 
>> On 13 Jan 2017, at 15:22, Gunnar Morling <gunnar@hibernate.org> wrote:
>>
>> As a variation of Matt's idea, an optional index() parameter could be added:
>>
>>   @Size(1)
>>   @Size(3)
>>   @ApplyConstraintTo(constraint=Size.class, index=1, target=WRAPPED_VALUE)
>>   List<String> nicknames;
>>
>> It could be omitted (via a default value of -1 or similar) if there is
>> only one constraint of the type in question:
>>
>>   @NotNull
>>   @Email
>>   @ApplyConstraintTo(constraint=NotNull.class, target=ANNOTATED_ELEMENT)
>>   Optional<String> email;
>>
>> Does the trick, though it's still a tad verbose.
>>
>>
>> 2017-01-13 14:58 GMT+01:00 Emmanuel Bernard <emmanuel@hibernate.org>:
>>>
>>> On 13 Jan 2017, at 13:29, Guillaume Smet <guillaume.smet@gmail.com> wrote:
>>>
>>> On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling <gunnar@hibernate.org>
>>> wrote:
>>>>
>>>> Unfortunately, validationAppliesTo() is already taken:
>>>>
>>>> http://beanvalidation.org/latest-draft/spec/#constraintsdefinitionimplementation-constraintdefinition-validationappliesto
>>>>
>>>> It's used to distinguish between return value and cross-parameter
>>>> constraints.
>>>>
>>>> Any other name I can think of right now would make up for much
>>>> confusion with that option.
>>>
>>>
>>> Too good to be true :).
>>>
>>> That being said, I'm wondering if we could reuse it and just add 2 other
>>> values to ConstraintTarget. All in all, it's the same concept. The default
>>> being IMPLICIT is not too bad either.
>>>
>>>
>>> Right I think it’s worth exploring.
>>> I still like my group repurposing trick though even if it offenses the clean
>>> camp :)
>>>

I still can't figure out how you would use the group trick in conjunction with validation of a "real" group.

Matt

 
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev


_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev