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@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@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-positive-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@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