Hi,
Michael mit with Stephen Colebourne during J1 this week and will write an
updated proposal around the date/time support based on the current one and
their discussions. Looking forward to it :)
--Gunnar
2016-09-23 7:18 GMT+02:00 Christian Kaltepoth <christian(a)kaltepoth.de>:
Hey Gunnar, Hey all,
> But if we design the TimeProvider this way, adding something to the
> method signature won't be possible in the future. However, I don't think
> this is a real problem. Unless someone comes up with some use case.
>
> It's a good point. I'd dislike adding a parameter object without any
> properties, "just in case", though. But this is a case where Java 8
> default methods are helpful: Should we ever see the need for some context
> parameter in a subsequent revision, we can add a new method for this and
> let it delegate to the parameterless one by default.
>
Sure, adding an empty parameter object would be a bad idea. And as I
mentioned before I cannot imagine any use case for providing additional
information to the provider. And if we want to add something in later spec
versions, we could use default methods as you described.
> Another thing: If @Future and @Past support types like LocalDate,
> YearMonth and Year, should we perhaps enhance them to allow the user to
> specify that the "current" year/month/date should also be valid?
>
> That's a very good point, too! This one has been specifically brought up
> with
https://hibernate.atlassian.net/browse/BVAL-466. It seems sensible
> to add an annotation parameter for this given the support for these
> non-instant types. When looking at your example, I'd have a hard time
> though to reason the exact semantics of inclusive(). I hope we could find
> something more descriptive?
>
I agree that "inclusive" isn't a good name. I'm open for any ideas.
;-)
Btw. Michael (who has been part of the JSR 310 EG) pointed out that
> TimeProvider should return a Clock.
>
I agree. We should use Clock.
Christian
--
Christian Kaltepoth
Blog:
http://blog.kaltepoth.de/
Twitter:
http://twitter.com/chkal
GitHub:
https://github.com/chkal
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev