[bv-dev] Questions from BV spec 2.0 public draft

[Gunnar Morling]

Hi,

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
> considered:
>
> * 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
per kind.

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:
https://hibernate.atlassian.net/browse/BVAL-211.

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
seems acceptable.

>
> * 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?

>
> Matt

--Gunnar

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