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

[Emmanuel Bernard]

On Wed 17-04-26 10:40, Gunnar Morling wrote:
>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?

I think that was my idea for not adding a hierarchy back in 1.x.

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

I don't even vaguely remember talking about it. Sounds good.
Actually I remember now, we discussed whether Positive#orZero should be
defaulted to true.

I imagine that >=0 is the most common use case for @Positive (despite
the math definition).
As for @Negative, I'm on the fence.

>
>@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
>_______________________________________________
>beanvalidation-dev mailing list
>beanvalidation-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/beanvalidation-dev