<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Ok I yield. </div><div>But you have to admit that making sure a signed int is always 0 or positive is probably the most common though low value usage you will find. And it's low value unless you factor security consideration at which stage it become a very very good idea to litter your code with these. </div><div><br></div><div>@Positive</div><div>int age, nbrOfApples, nbrOfFriends, starRatingAverage, votingParticipants;</div><div><br></div><div><br>On 10 May 2017, at 09:55, Marco Molteni <<a href="mailto:moltenma@gmail.com">moltenma@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">I'd go with default strict to true. It's supported by the mathematical definition of Positive/Negative number.<div><br><div>Very difficult to know the more common scenario (in a quick informal poll between developers near me everybody was confused).</div><div><br></div><div>I found this implementation of Zalando for a monetary amount and they use the strict interpretation for @Positive/Negative annotations and they added <span style="background-color:rgba(27,31,35,0.0470588);color:rgb(36,41,46);font-family:sfmono-regular,consolas,"liberation mono",menlo,courier,monospace;font-size:13.6px">@PositiveOrZero/</span><span style="background-color:rgba(27,31,35,0.0470588);color:rgb(36,41,46);font-family:sfmono-regular,consolas,"liberation mono",menlo,courier,monospace;font-size:13.6px">@NegativeOrZero</span><span style="background-color:rgba(27,31,35,0.0470588);color:rgb(36,41,46);font-family:sfmono-regular,consolas,"liberation mono",menlo,courier,monospace;font-size:13.6px"> to include the 0</span> : <a href="https://github.com/zalando/money-validation#usage">https://github.com/zalando/money-validation#usage</a> </div></div><div><br></div><div>The Eclipse Collections (ex-Goldman Sachs collections) defines positive number > 0 (strict case), <a href="https://github.com/goldmansachs/gs-collections">https://github.com/goldmansachs/gs-collections</a>. I would say that the more common scenario is to exclude the 0.</div><div><br></div><div>Marco</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 10, 2017 at 3:40 AM, Matt Benson <span dir="ltr"><<a href="mailto:mbenson@apache.org" target="_blank">mbenson@apache.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My last response might have made sense if I'd have sent my previous<br>
one (to Emmanuel) from the right address:<br>
<br>
"Less common" is an opinion. Are there survey data to back it up? By<br>
contrast, a literal or "strict" interpretation of past or future is<br>
something that cannot be questioned.<br>
<br>
;)<br>
<span class="HOEnZb"><font color="#888888"><br>
Matt<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Tue, May 9, 2017 at 6:52 PM, Matt Benson <<a href="mailto:mbenson@apache.org">mbenson@apache.org</a>> wrote:<br>
> That's why I advocate being literal; then you don't have to guess at<br>
> people's intention. Can't they compose a version that defaults strict to<br>
> false?<br>
><br>
> Matt<br>
><br>
> On May 9, 2017 6:22 PM, "Gunnar Morling" <<a href="mailto:gunnar@hibernate.org">gunnar@hibernate.org</a>> wrote:<br>
>><br>
>> 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<br>
>> >> <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<br>
>> >>>>> define<br>
>> >>>>> the same methods?<br>
>> >>>><br>
>> >>>> I've been wondering the same, but come to think that it doesn't give<br>
>> >>>> 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<br>
>> >>>> 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<br>
>> >>>>> 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<br>
>> >>>> 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<br>
>> >>>> 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<br>
>> >>> 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>
______________________________<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>
</div></div></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>beanvalidation-dev mailing list</span><br><span><a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a></span><br><span><a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a></span></div></blockquote></body></html>