[bv-dev] @Past(orPresent=true) -> @PastOrPresent?

[Gunnar Morling]

Hey Otavio,

Adding attributes for defining some kind of allowed range could be
done either way in the future, no matter whether it's
@Future(orPresent=) or @FutureOrPresent.

Could you describe in a bit more detail what you have in mind?

Thanks,

--Gunnar



2017-06-22 13:04 GMT+02:00 Otávio Gonçalves de Santana
<otaviopolianasantana at gmail.com>:
> I'm not a big fan of this option.
> I mean, who can we define the present?
> On the same API that will easy:
>
> YearMonth
> Year
> LocalDate
>
>
> But the API that cares about milliseconds? that will complicate, so we need
> to define a delta.
>
> LocalDateTime
> LocalTime
> Instant
>
>
> On Thu, Jun 22, 2017 at 4:15 AM, Marco Molteni <moltenma at gmail.com> wrote:
>>>
>>>  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 at 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 at 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 at 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 at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> >
>>> >
>>> > _______________________________________________
>>> > beanvalidation-dev mailing list
>>> > beanvalidation-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
>
>
> --
> Otávio Gonçalves de Santana
>
>
> twitter: http://twitter.com/otaviojava
> site:     http://about.me/otaviojava
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev