[bv-dev] Improved java.time support follow-up

[Gunnar Morling]

Thanks a lot for your feedback!

On 1., I was initially a bit skeptical about @Future for partial types such
as LocalTime or MonthDay, which don't denote "one point in time" but a
recurring one. But after playing a bit with those types in the RI, having
support for them felt alright.

On 2., agreed. People can always put their constraint to a derived member
with the right resolution as pointed out by Michael, so I don't think it
warrants explicit support.

On 3., ok, works for me.

Based on this feedback and the original proposal [1]. I've sent a pull
request for updating the spec (https://github.com/
beanvalidation/beanvalidation-spec/pull/122). Note that you need to take a
look at the API project, too, in order to get the full picture (as we
include API types directly from there).

Any comments on this change are welcome. I'll leave the PR open until the
end of the week end then merge it if nothing more comes up.

This change does not include support for range data types, I've opened
BVAL-553 [2] for that one. @Michael, maybe you are up for writing a
proposal for that one, too?

Thanks,

--Gunnar

[1] http://beanvalidation.org/proposals/BVAL-496/
[2] https://hibernate.atlassian.net/browse/BVAL-553



2017-01-08 12:43 GMT+01:00 Christian Kaltepoth <christian at kaltepoth.de>:

> Hey all,
>
> see my thoughts inline..
>
>
> 1. Support for partials
>>> ================
>>>
>>
>
>> [....]
>>>
>>> We tried to think of a use case but couldn't think of any.
>>>
>>
>> When you are using a calendar year for fiscal purposes (in Brazil, its
>> January-December), you could use MonthDay to represent a point in time
>> separately from the year. If a MonthDay represents a holiday, there might
>> be other use cases related to the current year.
>>
>>>
>>> That being said, it does not cost us anything to have it for consistency.
>>>
>>
>> Consistency for me is a good argument in itself. If we couldn't think of
>> the use case, maybe it's just because we're temporarily blind. Being
>> consistent doesn't hurt, especially given the effort is minimum :-)
>>
>
> I agree with Michael. I could imagine use cases especially in the context
> of financials (just think of a fiscal year for example). So I would prefer
> to be consistent and just support it.
>
>
>
>> 2. Resolution
>>> ==========
>>> [...]
>>>
>>> This would truncate the LocalDates to ChronoUnit.MONTHS before doing the
>>> comparison, ensuring that the date should be at least next month.
>>>
>>>
>> While this is a valid use case, it seems a little bit specific to me in
>> the sense you have a reference for "now" as a comparison (a use case I
>> mentioned before is validating a temporal object against an arbitrary
>> reference) and in this case converting it. This also limits the
>> "truncation" (which is just a specific case of conversion) to ChronoUnit,
>> when other types of conversion might be needed.
>>
>
> I don't think this is a very common use case. So I currently don't see a
> good reason to support it. But may be I'm missing a common use case here?
>
>
>
>>
>>
>>> 3. orPresent
>>> =========
>>> [...]
>>>
>>> Personally, I prefer having one annotation with an option rather than 2
>>> different annotations - I think it has a better semantic - but I can see
>>> the rationale behind Gunnar's proposal.
>>>
>>
>> I vote for one annotation.
>>
>
> I would also prefer one annotation. I think even something
> like @Past(resolution = DAY, orPresent = true) is quite good readable.
>
>
> Christian
>
>
> --
> Christian Kaltepoth
> Blog: http://blog.kaltepoth.de/
> Twitter: http://twitter.com/chkal
> GitHub: https://github.com/chkal
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170110/162e1435/attachment.html