[bv-dev] Method validation - cont'd

[Matt Benson]

On Mon, May 14, 2012 at 11:17 AM, Matt Benson <mbenson at apache.org> wrote:
> 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?
>

Actually, ruminating further on this... the approach I was thinking of
would require at least a partial implementation of a given class, just
to handle validation (any method result being discarded).  The
subclassing capability would be necessary regardless of whether only
interfaces were supported, so final methods would be the only thing
off-limits.

Matt

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