[bv-dev] Constructor validation

[Kevin Pollet]

On 7 December 2011 10:09, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

>
> >> 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 #2.
I think writing use cases is a good idea and they can be reused in the spec.


>
> >
> >>>> - 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20111207/33d099eb/attachment-0001.html