[bv-dev] Results on @Positive/@Negative poll

[Christian Kaltepoth]

I also prefer @PositiveOrZero/@NegativeOrZero over the @Non* annotation
names. So +1 for using the @*OrZero naming.

2017-05-24 18:01 GMT+02:00 Michael Nascimento <misterm at gmail.com>:

> The non-negative names are the way to go if we go the separate annotations
> route. I'm not a big fan of simply listening to the masses though and I'm
> wondering whether these annotations pull their weight, though. I feel more
> inclined towards orZero, which is the second most popular choice.
>
> Regards,
> Michael
>
>
> On Wed, May 24, 2017 at 6:10 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Hi all,
>>
>> We've received quite some good feedback on the poll on the behavior of
>> @Positive and @Negative (98 answers overall, see the original data
>> below).
>>
>> As per question 2), there's a preference for having separate
>> annotations instead of an attribute. I think the poll is clear enough
>> that we should go for the separate annotation route. While I was no
>> fan originally, it grew on me due to its explicitness.
>>
>> The remaining question is on their names. We had asked about
>> @PositiveOrZero/@NegativeOrZero in the poll, but several people
>> suggested @NonNegative and @NonPositive.
>>
>> Personally I'd prefer to stick to @PositiveOrZero/@NegativeOrZero
>> because I think negated names should be avoided generally, as
>> non-negated names are easier to grok (see? ;). And they'll be easier
>> to find via auto-completion in the IDE, i.e. when typing @Posit<TAB>,
>> you'll get both options shown, unlike when going for the @Non...
>> approach. But eventually I could live with both.
>>
>> Thoughts?
>>
>> --Gunnar
>>
>> Original poll data
>> =============
>> * When validating @Positive/@Negative, should 0 (zero) be considered
>> as valid by default?
>> - 58.2%: No, i.e. the following constraint is violated: private
>> @Positive int myNum= 0
>> - 41.8%: Yes, i.e. the following constraint is valid: private
>> @Positive int myNum =0
>>
>> * How should we call the constraint attribute for controlling whether
>> 0 is considered valid or not?
>> - 36.7%: no attribute, but rather add separate annotations:
>> @PositiveOrZero and at NegativeOrZero
>> - 28.6%: orZero(), e.g. used like so:@Positive(orZero=true)
>> - 25.5%: strict(), e.g. used like so:@Positive(strict=false)
>> - 9.2 %: others:
>>   - "@NonNegative/@NonPositive" (7x)
>>   - "Different annotation @Zero"
>>   - "Either make each explicit or use a @Range(min, max)"
>>
>> * Other related remarks:
>> - I think that 0(zero) should not be default, especially as it is
>> default for primitives. One should explicitly allow them, otherwise
>> users can forget to specify it.
>> - What's so bad about @Min(0) with inclusive again?
>> - "non-negative" is a well-established and widely used term for this
>> constraint
>> - The constraints are to fine a open closed range could do the same thing
>> - Java's logic was always from inclusive and to exclusive and that can
>> also be applied to 0.
>> - let's not create confusion by acting like "positive numbers"
>> includes zero. Developers can get over a little inconvenience of
>> @Positive not passing on values that aren't positive, such as 0.
>> - Do not be tempted to violate Bloch's api design rules. An API is
>> long-lived and making it incorrect to please early adopters is a poor
>> choice. https://www.infoq.com/articles/API-Design-Joshua-Bloch
>> - https://math.stackexchange.com/questions/26705/is-zero-posit
>> ive-or-negative
>> - Zero is mathematically neither positive not negative so please don't
>> throw math principle out. But the idea of attribute is a great thing
>> for usuability
>> - I would just use @Positive(> 0), @Negative (< 0), @NonNegative (>=
>> 0) and @NonPositive (<= 0) to make it more explicit, this also follows
>> the general rules found on sites such as Wikipedia:
>> https://en.wikipedia.org/wiki/Sign_(mathematics)#Terminology_for_signs
>> _______________________________________________
>> 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
>



-- 
Christian Kaltepoth
Blog: http://blog.kaltepoth.de/
Twitter: http://twitter.com/chkal
GitHub: https://github.com/chkal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170525/4d979608/attachment-0001.html