On Fri, Jan 13, 2017 at 10:23 AM, Matt Benson <mbenson(a)apache.org> wrote:
On Fri, Jan 13, 2017 at 8:57 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
> s/other/order from the JVM/
>
> > On 13 Jan 2017, at 15:54, Emmanuel Bernard <emmanuel(a)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(a)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(a)hibernate.org>:
> >>>
> >>> On 13 Jan 2017, at 13:29, Guillaume Smet
<guillaume.smet(a)gmail.com>
> wrote:
> >>>
> >>> On Fri, Jan 13, 2017 at 1:01 PM, Gunnar Morling
<gunnar(a)hibernate.org
> >
> >>> wrote:
> >>>>
> >>>> Unfortunately, validationAppliesTo() is already taken:
> >>>>
> >>>>
http://beanvalidation.org/latest-draft/spec/#constraintsdefi
> nitionimplementation-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
[1]
http://docs.oracle.com/javase/specs/jls/se8/html/jls-9.html#jls-9.7.5
> >>> _______________________________________________
> >>> 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
>