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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev