[bv-dev] Questions from BV spec 2.0 public draft
gunnar at hibernate.org
Wed Apr 26 04:40:16 EDT 2017
2017-04-25 20:05 GMT+02:00 Matt Benson <mbenson at apache.org>:
> After reviewing the proposed API, I have the following
> questions/suggestions. I apologize if any of these have already been
> * Should there be a common superinterface for
> Path$[BeanNode|PropertyNode|ContainerElementNode], all of which define
> the same methods?
I've been wondering the same, but come to think that it doesn't give you much.
You (as a user) are going to work with specific node types (as
narrowed down via getKind() + as()), so I would not expect you to deal
with that super-type in your code. It'd put the declaration of those
methods into one place, which is nice, though I kinda like the
simplicity of the current Node hierarchy, with one specific sub-type
What do others think?
> * Should ValidatorContext include a self type, as does Configuration?
> This would facilitate the use of custom ValidatorContext subclasses.
Ah, there's even an issue for this:
It would have been great to make this a self-referential type from the
get-go, but at this point I'd rather leave it as is. Essentially it
only causes a small effort to providers which need to redeclare all
the ValidatorContext methods to return their own specialised sub-type.
The reason I'm reluctant to add it is that users - when upgrading
existing code to BV 2.0 - will get a raw type warning when assigning
ValidatorContext to a variable. I'd prefer to avoid this, at the cost
of the few method re-definitions to be done by providers once, which
> * Should Positive/Negative#strict() default true be provided as
> #orZero() default false, for commonality with
> [Past|Future]#orPresent() ?
Hum, yes, good point. I think I'd prefer that.
@Emmanuel, I vaguely remember we discussed this. Did you see a good
reason for the current default?
@All, what do you think?
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
More information about the beanvalidation-dev