[bv-dev] Method validation - cont'd

[Matt Benson]

On Mon, May 14, 2012 at 11:01 AM, Emmanuel Bernard
<emmanuel at 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev