Is inclusive more common really? My feeling is that one would want to
exclude 0 more often than not. But I don't have any good idea of how
to quantify that...

2017-05-09 19:48 GMT+02:00 Emmanuel Bernard <emmanuel@hibernate.org>:
> Well I object :)
> You are addressing the less common scenario with this default.
>
>> On 9 May 2017, at 11:09, Gunnar Morling <gunnar@hibernate.org> wrote:
>>
>> 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@hibernate.org>:
>>>> On Wed 17-04-26 10:40, Gunnar Morling wrote:
>>>> Hi,
>>>>
>>>> 2017-04-25 20:05 GMT+02:00 Matt Benson <mbenson@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@lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev