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

[Gunnar Morling]

Hi all,

So my preference is to make strict() default to true (so it's
consistent with the default value for orPresent() of @Past/@Future).
I've filed PR https://github.com/beanvalidation/beanvalidation-api/pull/106.

If there are no objections by Thursday, I'll merge it then.

Thanks for any comments,

--Gunnar


2017-05-03 18:13 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> 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
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev