2012/5/14 Matt Benson <mbenson(a)apache.org>:
On Mon, May 14, 2012 at 11:17 AM, Matt Benson
<mbenson(a)apache.org> wrote:
> 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?
>
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.
Could you give some more details on the approach you have in mind?
Maybe some interfaces/methods etc. you're thinking about?
--Gunnar
Matt
> Matt
>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev