<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-10-26 9:02 GMT+02:00 Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_7794811310375165932gmail-">On Wed 16-10-19 12:09, Gunnar Morling wrote:<br>
>* Another interesting one is support for Unicode surrogate pairs (it's<br>
>mentioned several times, though I'm not sure whether that was not one and<br>
>the same person, given I've *never* heard about requests for it before).<br>
>The issue is that there are characters with a code unit greater than what<br>
>can be stored in two bytes. These are represented by "surrogate pairs",<br>
>causing for instance "𠮷".length() to return 2 and not 1 as one may expect.<br>
>Hence values given in @Size need to take that into account. I feel people<br>
>are best off with a custom validator addressing this case, but I'd be<br>
>curious to hear what others think. We may explore support in the RI.<br>
<br>
</span>About surrogate pairs, I am not at all familiar with it but could it be<br>
resolve with a provider specific global option to handle surrogate pairs<br>
or not.<br>
I suppose your reluctance to support it is because it will take extra<br>
CPU time for the common case correct?<br></blockquote><div><br></div>It's not that so much, but more staying consistent with the semantics of CharacterSequence/String#length().</div><div class="gmail_quote"><br></div><div class="gmail_quote">The docs of @Size say "length of character sequence is evaluated", so linking this to String#length() appears as the most natural and consistent thing to do.</div><div class="gmail_quote"><br></div><div class="gmail_quote">The docs of String#size() say "The length is equal to the number of Unicode code units in the string". I.e. the length of "𠮷" is defined as 2, not 1.</div><div class="gmail_quote"><br></div><div class="gmail_quote">I think the user is best off to implement their own validator or constraint @CodePointCount. We could make it an option in the RI or provide such constraint/validator in the RI, but then it's the first and only time I've heard about this requirement so I'm not sure whether it pulls its weight.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On another subject, one of the proposal was support for EL. Should we<br>
leave it to the providers? Or embrace it?<br></blockquote><div><br></div><div>Good question. We could promote @ScriptAssert from the RI. What do others think?</div><div><br></div><div>That remark in the survey was targeted towards cross-field validation, so we'd need some more work on top of that (@ScriptAssert is a pure class-level constraint atm.). I hope cross-field support to fall out of BVAL-214 by some kind of detyped validator API, i.e. EL wouldn't even be needed for this use case. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="m_7794811310375165932gmail-HOEnZb"><div class="m_7794811310375165932gmail-h5">______________________________<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>