OK I see now.
I am not sure I adhere to it but that's definitely interesting.
Some additional info:
- this can become a bit annoying or tricky if the method we want to validate methods from
has non default constructors setting final attributes - the validator implementation would
have to fake some of that
- this does not really address return value validation
On 15 mai 2012, at 17:57, Matt Benson wrote:
On Tue, May 15, 2012 at 3:44 AM, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
>
> On 14 mai 2012, at 18:21, Matt Benson wrote:
>
>>>
>>> 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.
>
> You have lost me :) Can you detail further what you are proposing, maybe with some
examples.
Okay, I have tried to organize my thoughts to some degree at
https://cwiki.apache.org/confluence/display/BVAL/inheritance-based+cross-...
.
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