<div dir="auto">That's why I advocate being literal; then you don't have to guess at people's intention. Can't they compose a version that defaults strict to false?<div dir="auto"><br></div><div dir="auto">Matt</div></div><div class="gmail_extra"><br><div class="gmail_quote">On May 9, 2017 6:22 PM, "Gunnar Morling" <<a href="mailto:gunnar@hibernate.org">gunnar@hibernate.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is inclusive more common really? My feeling is that one would want to<br>
exclude 0 more often than not. But I don't have any good idea of how<br>
to quantify that...<br>
<br>
2017-05-09 19:48 GMT+02:00 Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>>:<br>
> Well I object :)<br>
> You are addressing the less common scenario with this default.<br>
><br>
>> On 9 May 2017, at 11:09, Gunnar Morling <<a href="mailto:gunnar@hibernate.org">gunnar@hibernate.org</a>> wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> So my preference is to make strict() default to true (so it's<br>
>> consistent with the default value for orPresent() of @Past/@Future).<br>
>> I've filed PR <a href="https://github.com/beanvalidation/beanvalidation-api/pull/106" rel="noreferrer" target="_blank">https://github.com/<wbr>beanvalidation/beanvalidation-<wbr>api/pull/106</a>.<br>
>><br>
>> If there are no objections by Thursday, I'll merge it then.<br>
>><br>
>> Thanks for any comments,<br>
>><br>
>> --Gunnar<br>
>><br>
>><br>
>> 2017-05-03 18:13 GMT+02:00 Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>>:<br>
>>>> On Wed 17-04-26 10:40, Gunnar Morling wrote:<br>
>>>> Hi,<br>
>>>><br>
>>>> 2017-04-25 20:05 GMT+02:00 Matt Benson <<a href="mailto:mbenson@apache.org">mbenson@apache.org</a>>:<br>
>>>>> After reviewing the proposed API, I have the following<br>
>>>>> questions/suggestions. I apologize if any of these have already been<br>
>>>>> considered:<br>
>>>>><br>
>>>>> * Should there be a common superinterface for<br>
>>>>> Path$[BeanNode|PropertyNode|<wbr>ContainerElementNode], all of which define<br>
>>>>> the same methods?<br>
>>>><br>
>>>> I've been wondering the same, but come to think that it doesn't give you much.<br>
>>>><br>
>>>> You (as a user) are going to work with specific node types (as<br>
>>>> narrowed down via getKind() + as()), so I would not expect you to deal<br>
>>>> with that super-type in your code. It'd put the declaration of those<br>
>>>> methods into one place, which is nice, though I kinda like the<br>
>>>> simplicity of the current Node hierarchy, with one specific sub-type<br>
>>>> per kind.<br>
>>>><br>
>>>> What do others think?<br>
>>><br>
>>> I think that was my idea for not adding a hierarchy back in 1.x.<br>
>>><br>
>>>><br>
>>>>><br>
>>>>> * Should ValidatorContext include a self type, as does Configuration?<br>
>>>>> This would facilitate the use of custom ValidatorContext subclasses.<br>
>>>><br>
>>>> Ah, there's even an issue for this:<br>
>>>> <a href="https://hibernate.atlassian.net/browse/BVAL-211" rel="noreferrer" target="_blank">https://hibernate.atlassian.<wbr>net/browse/BVAL-211</a>.<br>
>>>><br>
>>>> It would have been great to make this a self-referential type from the<br>
>>>> get-go, but at this point I'd rather leave it as is. Essentially it<br>
>>>> only causes a small effort to providers which need to redeclare all<br>
>>>> the ValidatorContext methods to return their own specialised sub-type.<br>
>>>><br>
>>>> The reason I'm reluctant to add it is that users - when upgrading<br>
>>>> existing code to BV 2.0 - will get a raw type warning when assigning<br>
>>>> ValidatorContext to a variable. I'd prefer to avoid this, at the cost<br>
>>>> of the few method re-definitions to be done by providers once, which<br>
>>>> seems acceptable.<br>
>>>><br>
>>>>><br>
>>>>> * Should Positive/Negative#strict() default true be provided as<br>
>>>>> #orZero() default false, for commonality with<br>
>>>>> [Past|Future]#orPresent() ?<br>
>>>><br>
>>>> Hum, yes, good point. I think I'd prefer that.<br>
>>>><br>
>>>> @Emmanuel, I vaguely remember we discussed this. Did you see a good<br>
>>>> reason for the current default?<br>
>>><br>
>>> I don't even vaguely remember talking about it. Sounds good.<br>
>>> Actually I remember now, we discussed whether Positive#orZero should be<br>
>>> defaulted to true.<br>
>>><br>
>>> I imagine that >=0 is the most common use case for @Positive (despite<br>
>>> the math definition).<br>
>>> As for @Negative, I'm on the fence.<br>
>>><br>
>>>><br>
>>>> @All, what do you think?<br>
>>>><br>
>>>>><br>
>>>>> Matt<br>
>>>><br>
>>>> --Gunnar<br>
>>>><br>
>>>>> ______________________________<wbr>_________________<br>
>>>>> beanvalidation-dev mailing list<br>
>>>>> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.<wbr>jboss.org</a><br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/<wbr>beanvalidation-dev</a><br>
>>>> ______________________________<wbr>_________________<br>
>>>> beanvalidation-dev mailing list<br>
>>>> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.<wbr>jboss.org</a><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/<wbr>beanvalidation-dev</a><br>
>>> ______________________________<wbr>_________________<br>
>>> beanvalidation-dev mailing list<br>
>>> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.<wbr>jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/<wbr>beanvalidation-dev</a><br>
>> ______________________________<wbr>_________________<br>
>> beanvalidation-dev mailing list<br>
>> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.<wbr>jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/<wbr>beanvalidation-dev</a><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.<wbr>jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/<wbr>beanvalidation-dev</a><br>
______________________________<wbr>_________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.<wbr>jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/<wbr>beanvalidation-dev</a><br>
</blockquote></div></div>