Re: [bv-dev] Method validation - cont'd

On Mon, May 14, 2012 at 11:01 AM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > > On 14 mai 2012, at 17:53, Matt Benson wrote: > >> On Mon, May 14, 2012 at 10:48 AM, Emmanuel Bernard >> <emmanuel(a)hibernate.org&gt; wrote: >>> >>> On 14 mai 2012, at 17:18, Matt Benson wrote: >>> >>>>>> >>>>>> * Should method validation methods be defined on j.v.Validator or a >>>>>> dedicated new interface? >>>>> >>>>> Should be on javax.validation.Validator >>>> >>>> Destroying backward compatibilty?  Not such a big deal for full-blown >>>> implementations, perhaps, but what about interoperability libraries >>>> that may, for whatever reason, implement javax.validation.Validator? >>>> Shouldn't a user be able to upgrade to a Bean Validation 1.1 >>>> implementation and still use libraries built against Bean Validation >>>> 1.0? >>> >>> No I don't think that's a realistic goal. It would force us to use some untyped unwrap() style method to >>> add features to Bean Validation. >> >> But isn't that the reason #unwrap() is part of the Validator and >> ValidatorFactory interfaces? > > The reason we put it in there is for implementors to be able to offer extensions more easily. Of > course we could use unwrap to do as you said but it seems to me that would undermine the UX > to please frameworks wrapping BV calls. note that they could use a dynamic proxy instead of a > static delegator pattern to be API change proof. Interesting point, the more so because I was about to suggest a proxy-based variation of cross-parameter validation approach #3. Maybe interface-only per spec, with subclassing as an optional extension.  Thoughts?

Matt > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev