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

[Michael Nascimento]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170524/35103c54/attachment.html