as they are a bit shorter to use and, more importantly, better to
 read.

I agree.

 It's late in the game, but I feel inclined to extract @PastOrPresent
 and @FutureOrPresent. What do you think?


Ok for me.



On Wed, Jun 21, 2017 at 7:33 PM, Gunnar Morling <gunnar@hibernate.org> wrote:
Just from - very quickly - thinking, no options are coming to my mind.

Note that we're about to push the Proposed Final Draft (CR1) with the
separate annotations in a bit. We still an re-consider until the Final
if something strongly speaks against it, but it seemed like the more
likely option to me and the PFD should be out today so it's up online
by the end of the week.

I wish the question would have come up earlier so it wouldn't be such
a rush, but well...


2017-06-21 19:00 GMT+02:00 Emmanuel Bernard <emmanuel@hibernate.org>:
> My argument against is that @Past / @Future could need additional options: like maybe past per year or month instead of instant time. I understand we do use the type structure to extract that information.
> Is there potential options people can think of around time constraints?
>
> For @Positive/@Negative, we decided there were none.
>
>> On 21 Jun 2017, at 11:50, Gunnar Morling <gunnar@hibernate.org> wrote:
>>
>> Hi all,
>>
>> A colleague of mine reviewing the BV 2.0 changes pointed out an
>> inconsistency in the added/modified constraints.
>>
>> As per the community poll we have now @NegativeOrZero and
>> @PositiveOrZero, whereas we still have the orPresent() option on @Past
>> and @Future. Should it be @PastOrPresent and @FutureOrPresent instead
>> for the sake of consistency?
>>
>> Now one could argue that having only attributes (orPresent(),
>> orZero()) is most consistent with other constraints such as
>> @DigitalMin. But indeed the explicit annotations grew on me over time
>> as they are a bit shorter to use and, more importantly, better to
>> read.
>>
>> It's late in the game, but I feel inclined to extract @PastOrPresent
>> and @FutureOrPresent. What do you think?
>>
>> Thanks,
>>
>> --Gunnar
>> _______________________________________________
>> 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
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev