[bv-dev] Method Validation: Why Example 4.11 should be allowed

Emmanuel Bernard emmanuel at hibernate.org
Mon Aug 27 10:49:23 EDT 2012


I think Gunnar explained that somewhere in this thread but here is the gist.

There is a difference between what goes in (parameters) and what goes out (return values) of a method.

As a client, if your subclass returns me a more constrained result that what was advertised that's ok, I can still work with it as I receive it.
However when I pass parameter values to a method, things are different, if you make it more constrained, a parameter that is supposed to pass according to my contract does not pass if a subclass implementation happens to be used.

Getters are methods returning values and thus can be refined by subclasses.

On 27 août 2012, at 16:35, Paul Benedict wrote:

> Thanks Emmanuel. I am sure the poll will bring interesting results.
> 
> In the mean time, I am looking for some background information here. I
> would like to understand this reasoning a bit better. As I said, I was
> reading the Hibernate Validator guide and read (not news to me) that
> annotations on beans can be compounded: "Constraint annotations are
> aggregated if methods are overridden."
> 
> Yet one of the arguments made to me (against allowing constraint
> redefinition on methods) is that the caller doesn't know if
> redefinition occurred. However, I see that's exactly the case today
> regarding constraint inheritance on beans -- subclasses can add more
> constraints by overriding superclass methods. So a client might be
> using a subclass, unbeknownst to the client, that has more constraints
> than what superclass/interface he compiled against.
> 
> My question is really why treat validation different between beans and
> method parameters? Why allow the former but disallow the latter? The
> way we treat beans today is what I would expect even for method
> validation (hence my emails). I honestly see no difference so I find
> the difference in validating behavior puzzling. My question isn't
> rhetorical so any answer is appreciated to help better understand the
> opposing perspective. Thank you.
> 
> Paul
> 
> On Mon, Aug 27, 2012 at 9:12 AM, Emmanuel Bernard
> <emmanuel at hibernate.org> wrote:
>> Just to get a better understanding of the dynamic here.
>> Can you all vote on what you think is the best approach for Bean Validation 1.1
>> http://www.doodle.com/qp78u6mqzetuas7p
>> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev




More information about the beanvalidation-dev mailing list