4:10 a.m.
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
11:01 a.m.
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(a)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-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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
4:25 a.m.
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(a)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(a)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-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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)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
3:55 a.m.
2017-05-24 18:01 GMT+02:00 Michael Nascimento <misterm(a)gmail.com>:
The non-negative names are the way to go if we go the separate
annotations
route.
Can you elaborate on your reasoning?
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.
Ok, but I think it'd be bad form to first ask for feedback and then
not follow the expressed preference. Also I think this is mostly a
question of style, it's not a black and white thing. So let's follow
the community feedback here.
Regards,
Michael
On Wed, May 24, 2017 at 6:10 AM, Gunnar Morling <gunnar(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
11:19 a.m.
On Fri, May 26, 2017 at 5:55 AM, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
2017-05-24 18:01 GMT+02:00 Michael Nascimento
<misterm(a)gmail.com>:
> The non-negative names are the way to go if we go the separate
annotations
> route.
Can you elaborate on your reasoning?
OUCH, I meant the non-non-negative aka PositiveOrZero / NegativeOrZero.
Sorry for that. It just shows how confusing negative names are :-)
> 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.
Ok, but I think it'd be bad form to first ask for feedback and then
not follow the expressed preference.
I respect your reasoning. However, the difference is not statistically
significant and we are going for the second option, which shows we're
listening to a degree.
Also I think this is mostly a question of style, it's not a black
and
white thing.
That's for sure.
Regards,
Michael
2:25 a.m.
Hi,
These are the PRs for adding @PositiveOrZero and @NegativeOrZero:
* https://github.com/beanvalidation/beanvalidation-api/pull/111
* https://github.com/beanvalidation/beanvalidation-spec/pull/183
--Gunnar
2017-05-26 18:19 GMT+02:00 Michael Nascimento <misterm(a)gmail.com>:
On Fri, May 26, 2017 at 5:55 AM, Gunnar Morling
<gunnar(a)hibernate.org>
wrote:
>
> 2017-05-24 18:01 GMT+02:00 Michael Nascimento <misterm(a)gmail.com>:
> > The non-negative names are the way to go if we go the separate
> > annotations
> > route.
>
> Can you elaborate on your reasoning?
OUCH, I meant the non-non-negative aka PositiveOrZero / NegativeOrZero.
Sorry for that. It just shows how confusing negative names are :-)
>
> > 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.
>
> Ok, but I think it'd be bad form to first ask for feedback and then
> not follow the expressed preference.
I respect your reasoning. However, the difference is not statistically
significant and we are going for the second option, which shows we're
listening to a degree.
>
> Also I think this is mostly a question of style, it's not a black and
> white thing.
That's for sure.
Regards,
Michael
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
2724
days inactive
2738
days old
beanvalidation-dev@lists.jboss.org
5 comments
3 participants
participants (3)
-
Christian Kaltepoth -
Gunnar Morling -
Michael Nascimento