On Mon, May 14, 2012 at 11:01 AM, Emmanuel Bernard
<emmanuel(a)hibernate.org> 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> 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