<div dir="ltr">> <span style="font-family:arial,sans-serif;font-size:13px">two elements brings the aditional complexity of the incompatible</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px"> combinations or even expected behavior when considering weird</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px"> combinations.</span><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">I see your point.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">OTOH, also in the current model a user </span><span style="font-family:arial,sans-serif;font-size:13px">could specify something incompatible like { NONE, CONSTRUCTORS }. In both models we mitigate the risk for inconsistent use by</span><span style="font-family:arial,sans-serif;font-size:13px"> properly documenting the behavior, but personally I'd find two separate attributes, each with clear semantics, "harder" to use wrong than one enum with mixed values.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Or, to put it in other words, the precedence of an enabled/disabled switch over another attribute controlling the enabled behavior seems to me more natural and intuitively understandable than the </span><span style="font-family:arial,sans-serif;font-size:13px">{ NONE, CONSTRUCTORS } case which only can be resolved by documentation.</span></div>
<div><br></div><div style>But in the end that's details, both approaches surely work.</div><div style><br></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px">--Gunnar</span></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/2/15 Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">We discussed that be to me:<br>
- two annotations do make things more complex IMO and thus go against<br>
the goal here. Esp with annotations with similar names<br>
- two elements brings the aditional complexity of the incompatible<br>
combinations or even expected behavior when considering weird<br>
combinations.<br>
<br>
I'd rather live with a slightly awkward enum.<br>
<span><font color="#888888"><br>
Emmanuel<br>
</font></span><div><div><br>
On Fri 2013-02-15 15:58, Gunnar Morling wrote:<br>
> I agree with what Hardy said.<br>
><br>
> Alternatively we could have one annotation with two attributes:<br>
><br>
> @ValidateExecutables(enabled=true/false,<br>
> types=ALL|CONSTRUCTORS|GETTERS|NON_GETTERS)<br>
><br>
> Where enabled = true by default and types = ALL by default. types would<br>
> only be considered if enabled = true.<br>
><br>
> //enable validation for type<br>
> @ValidateExecutables<br>
> public class Foo {<br>
><br>
> }<br>
><br>
> //exclude getters<br>
> @ValidateExecutables(types={CONSTRUCTORS, NON_GETTERS})<br>
> public class Foo {<br>
><br>
> }<br>
><br>
> @ValidateExecutables<br>
> public class Foo {<br>
><br>
> @ValidateExecutables(enabled=false)<br>
> public getFoo() { ... }<br>
> }<br>
><br>
> This would avoid the mixing of two things in one enum as mentioned by Hardy<br>
> and also circumvent the naming issue. On a single method,<br>
> @ValidateExecutables(enabled=false) is still a bit lengthy, but I think<br>
> it's better than @ValidateExecutables(types = NONE).<br>
><br>
> --Gunnar<br>
><br>
><br>
><br>
> 2013/2/15 Hardy Ferentschik <<a href="mailto:hardy@hibernate.org" target="_blank">hardy@hibernate.org</a>><br>
><br>
> > Hi,<br>
> ><br>
> > To have a enum which truly makes sense we would have to go for two<br>
> > annotations.<br>
> ><br>
> > We try to mix two semantics into a single emum. One is the on/off switch<br>
> > and one<br>
> > is the types of executables to validate. No matter how you rename the enum<br>
> > will always<br>
> > read awkward unless we separate these two things.<br>
> ><br>
> > I could live with @ValidateExecutables and @ValidateExecutable. I don't<br>
> > think that it<br>
> > is a problem that in other contexts the @Xs is a list of @X annotations.<br>
> ><br>
> > --Hardy<br>
> ><br>
> ><br>
> > On 14 Jan 2013, at 5:55 PM, Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>><br>
> > wrote:<br>
> ><br>
> > > Pete from CDI gave me the same feedback.<br>
> > ><br>
> > > There are a few competing alternatives<br>
> > ><br>
> > > ## enum adjustments<br>
> > ><br>
> > > @ValidateExecutable.type defaults to ALL<br>
> > > and rename ElementType.NONE to ElementType.OFF or NO<br>
> > ><br>
> > > We can even rename type to value to make the user even easier at the<br>
> > > risk of harder evolutions if we need to add more parameters down the<br>
> > > road.<br>
> > ><br>
> > > ## two annotations<br>
> > ><br>
> > > @ValidateExecutable(ON|OFF) targeting methods and constructors<br>
> > > @ValidateExecutables(ALL|NON_GETTER_METHODS|...)<br>
> > ><br>
> > > The downside is that the @Xxxs convention is used to add several times<br>
> > > the same annotation. This is widely used in EE for example.<br>
> > ><br>
> > > We could try and find better (different) names for these annotations but<br>
> > > I could not find a good set.<br>
> > ><br>
> > > What are your preferences?<br>
> > ><br>
> > > On Mon 2013-02-11 11:04, Emmanuel Bernard wrote:<br>
> > >> Santiago from the JAX-RS EG is concerned that we have created an<br>
> > >> over-engineered solution to enable / disable method validation on a per<br>
> > >> method basis.<br>
> > >> We have good reasons for it but I am wondering if we can make it a bit<br>
> > >> easier to enable or disable methods out of the box.<br>
> > >><br>
> > >> Remember, the default is to ignore getters. If we make<br>
> > >> @ValidateExecutable.type default to ALL, enabling it on a getter would<br>
> > >> be<br>
> > >><br>
> > >> @NotEmpty @ValidateExecutable<br>
> > >> public String getAction() {...}<br>
> > >><br>
> > >> instead of<br>
> > >><br>
> > >><br>
> > >> @NotEmpty @ValidateExecutable(type=ExecutableType.ALL)<br>
> > >> public String getAction() {...}<br>
> > >><br>
> > >> We would still need the verbose approach to disable validation<br>
> > >><br>
> > >> @NotEmpty @ValidateExecutable(type=ExecutableType.NONE)<br>
> > >> public String getAction() {...}<br>
> > >><br>
> > >> I am open to suggestions to make that easier on methods. I don't think<br>
> > >> an additional annotation will make anything easier<br>
> > >><br>
> > >> Maybe renaming NONE with OFF might help? It's a bit weirder on a<br>
> > >> class-level but that might work.<br>
> > >><br>
> > >> Thoughts?<br>
> > >><br>
> > >> Emmanuel<br>
> > >> _______________________________________________<br>
> > >> beanvalidation-dev mailing list<br>
> > >> <a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
> > >> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
> > > _______________________________________________<br>
> > > beanvalidation-dev mailing list<br>
> > > <a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
> > > <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > beanvalidation-dev mailing list<br>
> > <a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
> ><br>
<br>
> _______________________________________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
<br>
_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
</div></div></blockquote></div><br></div></div>