Results on @Positive/@Negative poll
by Gunnar Morling
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
5 years, 12 months
- 3
- 5
OverridesAttribute questions
by Matt Benson
I have a couple of questions about @OverridesAttribute:
1. The spec says that #name() defaults to the name of the annotated
attribute, but there is actually no default value declared. Should(n't) we
declare as ""?
2. I don't have a clear understanding from the spec what the expectations
are if there is a single override specified using the default
constraintIndex value, but with multiple composing constraints of the
specified type. Does the override apply to all? Is it an error?
Matt
5 years, 12 months
- 2
- 2