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--
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/ beanvalidation-dev