>> Note that return type constraints could be refined theoretically and be compliant with the Liskov substitution principle. We might want to still disallow this to limit confusion. It will all depend on the set of use case we can think of.
>
> In HV we are currently allowing to define additional return value
> constraints on methods overridden in sub types, and so far I haven't
> heard of any problems with that. AFAICS that's also what most
> programming by contract solutions do.
>
> What's your opinion on parameter constraints? Would you prefer to
> OR-join them or to prohibit constraints in overridden methods at all?

I am neutral to against in the ground that it's not exactly trivial to understand and that the fact that return values behave differently is counter-intuitive even if it's logical. My logic applies for letting returned type be refined.

We have three options:

1. not allow refinement
2. allow return value refinement (AND style)
3. allow param (OR style) and return value (AND style) refinement

We can go from 1 to 3 in the lifetime of the spec but not back.

What do others think? Could we work out 3-5 use cases for each to better see the merit of refinement?

>
>>>> - When you add a method return value constraint to a parameterized
>>>> method and you do Validator.validate(object), thoses constraints are not
>>>> evaluated. But when you add a constraint to a getter-style method (which
>>>> also looks and actually is a method return value constraint). They are
>>>> evaluated by Validator.validate(object). What if someone wants to add a
>>>> method return value constraint to a getter-style method, that is not
>>>> evaluated when Validator.validate(object) is executed but after the
>>>> method itself has been invoked? In OVal you have to explicitely add the
>>>> @IsInvariant annotation to getter methods if their constraints should be
>>>> evaluated too when Validator.validate(object) is executed. If so, OVal
>>>> will invoke the getter and test the returned value against the
>>>> constraints specified.
>>>
>>> Personally I'd say getters are methods such as any other methods, too.
>>> So if a getter method is invoked one some bean generally qualifying
>>> for method validation (however that is decided by the method
>>> validation integration layer) the method's constraints should be
>>> validated in the same way as any other method constraints. If the bean
>>> is validated using Validator#validate(), the getter method's
>>> constraints should be handled as property constraints as it's the case
>>> today IMO.
>>
>> @IsInvariant is not much different from a group (though a bit more elegant). I don't think we should add something explicit in the spec to address this problem as we already can solve it with groups.
>> Note that getters are not like ordinary methods, they are (by convention) Java properties and that's exactly what validator.validate processes (properties).
>
> Yes, getters are considered as properties for standard bean validation
> (Validator#validate()). But in the context of method validation I
> would handle them as return value constraints as on any other method.
>
> If I understand correctly, @IsInvariant as described above would be
> breaking with the current spec behavior as it is needed to explicitly
> enable a constraint on a getter for property validation, which is in
> BV the case by default.
>
> Using groups for cases, where a getter's constraints should be handled
> different for property and method validation seems reasonable to me,
> too.

I have a small concern with that. Granted is compatible with the spec but if people have been investing in constraints that are validated at specific time, should we carry them by default as legit method constraints validated upon calls (that's assuming some AOP style interception)?

>
> An additional idea would be some option to apply a getter's
> constraints also as method parameter constraints on the corresponding
> setter. So if method validation for that bean is enabled, illegal
> values couldn't be set at all. Would that be useful?

Global setting or local setting?

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev