<div dir="ltr">Michael I see the business case for the Period validation, but the complexity (impossibility) of a reliable comparison between Periods it seems widespread and accepted between the developers. Personally I don't see the benefits to have it in the spec if it risks to generate confusion or errors.<div><br></div><div>If you have some inputs, these are welcome. Could you enrich your previous example (years, month, days)?<br></div><div><div><br></div><div>Thanks</div><div><br><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 21, 2017 at 8:51 AM, Gunnar Morling <span dir="ltr"><<a href="mailto:gunnar@hibernate.org" target="_blank">gunnar@hibernate.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>2017-02-20 20:13 GMT+01:00 Michael Nascimento <<a href="mailto:misterm@gmail.com" target="_blank">misterm@gmail.com</a>>:<br>
> On Fri, Feb 17, 2017 at 5:11 AM, Gunnar Morling <<a href="mailto:gunnar@hibernate.org" target="_blank">gunnar@hibernate.org</a>><br>
> wrote:<br>
>><br>
>> > You don't compare, because they are not the same. The idea is that the<br>
>> > Period must be defined in terms of the units for which you defined its<br>
>> > boundaries.<br>
>><br>
>> I see. I'm wondering though how practical that will be. Will the<br>
>> developer who puts the constraint always know the structure of the<br>
>> Period set to the field (data set by the application user)?<br>
><br>
><br>
> In the case you want it to be validated, you ought to :-)<br>
<br>
</span>But that's the problem, can you really?<br>
<br>
The actual field values are set at application runtime, e.g. entered<br>
by a user sitting in front of the application. So the application<br>
developer would have to "lock down" whatever can be put in to match<br>
the unit set in the constraint. It's doable but I'm having doubts that<br>
this constraint pulls its eight eventually.<br>
<span><br>
><br>
>><br>
>><br>
>> > You shouldn't support threeten-extra, but rather arbitrary<br>
>> > TemporalAmounts.<br>
>> > Then threeten-extra just happen to be one of those. There must be<br>
>> > something<br>
>> > like @ChronoUnitMax/@ChronoUnitMin such as:<br>
>> ><br>
>> > @ChronoUnitMax(unit=DAYS, value=1)<br>
>><br>
>> How would that look like for a Period with several elements set, e.g.<br>
>> "3 months, 2 days"? Would we need a dedicated member in @ChronoUnitMax<br>
>> for each value of ChronoUnit (which are a lot)?<br>
><br>
><br>
> What do you mean by a member in @ChronoUnitMax? In my example, I suggest<br>
> using unit as a member, leading to unit and value being the only members.<br>
<br>
</span>By member I meant months(), days(), hours() etc. In the "one unit, one<br>
value" model, how would you express "max 3 month and two weeks"? We<br>
could exclude such case of course, it may sufficiently well be<br>
expressed as "max 10 weeks".<br>
<span class="m_-3713390949554749298im m_-3713390949554749298HOEnZb"><br>
><br>
>><br>
>> We had a discussion of Duration et al. a while ago, but it petered<br>
>> out. So we thought we'd add something to the RI to spark a new<br>
>> discussion. Seems it worked :)<br>
><br>
><br>
> Can´t disagree :-)<br>
><br>
> Regards,<br>
> Michael<br>
><br>
</span><div class="m_-3713390949554749298HOEnZb"><div class="m_-3713390949554749298h5">> ______________________________<wbr>_________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss<wbr>.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/beanvalidation-dev</a><br>
<br>
______________________________<wbr>_________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss<wbr>.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/beanvalidation-dev</a></div></div></blockquote></div><br></div></div></div></div>