Re: [bv-dev] Constructor validation
>> 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?
+1 for option #2
>> @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.
I guess you can solve the problem with groups somehow, but this probably means that you
have to pull all your method constraints into a group. As you already say, it is not
elegant.
I think something like @IsInvariant or @InvariantOnly is a much more expressive solution
and is also backward compatible. We are just extending existing functionality.
>> Note that getters are not like ordinary methods, they are (by
convention) Java properties and that's exactly what validator.validate processes
(properties).
Not all getters are necessary properties.
> 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?
Could we have an example for this? I don't quite get what this is about.
--Hardy