<div dir="ltr">Hi,<div><br></div><div>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 :)</div><div><br></div><div>--Gunnar</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-09-23 7:18 GMT+02:00 Christian Kaltepoth <span dir="ltr"><<a href="mailto:christian@kaltepoth.de" target="_blank">christian@kaltepoth.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey Gunnar, Hey all,<div><br><div><br><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span><div>> <span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px"><br></span></div></span><div><span style="font-size:12.8px">It's a good point. I'd dislike adding a parameter object </span><span style="font-size:12.8px">without any properties</span><span style="font-size:12.8px">, "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.</span></div></div></div></blockquote><div><br></div></span><div>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.</div><span class=""><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span><div><span style="font-size:12.8px">> </span>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?</div><div><br></div></span><div>That's a very good point, too! This one has been specifically brought up with <a href="https://hibernate.atlassian.net/browse/BVAL-466" target="_blank">https://hibernate.atlassi<wbr>an.net/browse/BVAL-466</a>. 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?</div></div></div></blockquote><div><br></div></span><div>I agree that "inclusive" isn't a good name. I'm open for any ideas. ;-)</div><span class=""><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Btw. Michael (who has been part of the JSR 310 EG) pointed out that TimeProvider should return a Clock.<br></div></div></blockquote><div><br></div></span><div>I agree. We should use Clock.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div><br></div><div>Christian</div><div><br></div></font></span></div><span class=""><div><br></div>-- <br><div data-smartmail="gmail_signature"><div>Christian Kaltepoth</div><div>Blog: <a href="http://blog.kaltepoth.de/" target="_blank">http://blog.kaltepoth.de/</a></div><div>Twitter: <a href="http://twitter.com/chkal" target="_blank">http://twitter.com/chkal</a></div><div>GitHub: <a href="https://github.com/chkal" target="_blank">https://github.com/chkal</a></div><div><br></div></div>
</span></div></div></div></div>
<br>______________________________<wbr>_________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.<wbr>jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/<wbr>beanvalidation-dev</a><br></blockquote></div><br></div>