<div dir="ltr">Gunnar,<div><br></div><div>Maybe I'm missing the point here, but as far as I understand, names added to the paths will be significant - for instance, it will influence how messages will end up being formatted, because keys will now depend on this additional information, right? If this is wrong, then disregard what I wrote below because it's based on that assumption.</div><div><br></div><div>When you rename a property or a class name, client code will very likely fail to compile. You're releasing an incompatible change - you probably need to bump your major version in some cases and write thorough release notes in order to do that. Now, we're saying that to BeanValidation - and so far, in JCP standards, the only one AFAIK -, type parameter *names* are relevant. If you rename one, your code will compile but you might end up having a runtime exception or a poorly formatted error message because of that, unless you explicitly test them for type parameter name change - the only change that will not break other parts of your code. Whereas if you really on order, a change either breaks compilation or completely changes the semantics of existing code and has to follow the incompatible change process.</div><div><br></div><div>But, as I said, what I said above is only valid if the names are significant, i.e., used somewhere else in a meaningful way.</div><div><br></div><div>Regards,</div><div>Michael</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 22, 2017 at 2:13 PM, 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 class="">> Looks bad, type parameter names in Java are considered documentation and not<br>
> something you cannot change during class evolution. For Map, it won't ever<br>
> change, but for other domain classes, it can change.<br>
<br>
</span>Property paths reflect on a model in a given state. If your model<br>
evolves, e.g. because you rename a bean property, paths obtained<br>
previously may not match any element in the model's current state<br>
anymore.<br>
<br>
I.e. I'm failing to see the how the situation is fundamentally<br>
different for type parameters?<br>
<div><div class="h5"><br>
2017-02-22 17:46 GMT+01:00 Michael Nascimento <<a href="mailto:misterm@gmail.com">misterm@gmail.com</a>>:<br>
> On Wed, Feb 22, 2017 at 1:10 PM, Guillaume Smet <<a href="mailto:guillaume.smet@gmail.com">guillaume.smet@gmail.com</a>><br>
> wrote:<br>
>><br>
>> = 1. Type parameter information<br>
>><br>
>> == 1.1 Should we add the type parameter to the node?<br>
>><br>
>> Assume the example of a map:<br>
>> private Map<@Valid City (1), @Valid Statistics (2)> map;<br>
>><br>
>> With the current way of doing things, you end up with the following paths:<br>
>> (1) (name = map, type = PROPERTY) -> (name = name, type = PROPERTY,<br>
>> isInIterable = true, key = city)<br>
>> (2) (name = map, type = PROPERTY) -> (name = count, type = PROPERTY,<br>
>> isInIterable = true, key = city)<br>
>><br>
>> So you wouldn't be able to differentiate if the violations is coming from<br>
>> City or Statistics.<br>
>><br>
>> One of the ideas we had is to integrate the TypeVariable<?> type parameter<br>
>> info into the last node. In the case of (1), you would have 2 nodes:<br>
>> (1) (name = map, type = PROPERTY) -> (name = name, type = PROPERTY,<br>
>> isInIterable = true, key = city, typeParameter = K)<br>
>> (2) (name = map, type = PROPERTY) -> (name = count, type = PROPERTY,<br>
>> isInIterable = true, key = city, typeParameter = V)<br>
>><br>
>> WDYT?<br>
><br>
><br>
> Looks bad, type parameter names in Java are considered documentation and not<br>
> something you cannot change during class evolution. For Map, it won't ever<br>
> change, but for other domain classes, it can change.<br>
><br>
> Type parameter *order*, though, cannot change without change meaning, so<br>
> that's the best option we have left :-(<br>
><br>
>><br>
>> == 1.2 If we add this information, what should it be?<br>
>><br>
>> At first, Gunnar thought about using java.lang.reflect.TypeVariable for<br>
>> this type parameter information but we have an issue with it: it is not<br>
>> serializable and the path is supposed to be.<br>
>><br>
>> Thus we need to either use a String with the name of the type parameter or<br>
>> introduce our own serializable structure.<br>
><br>
><br>
> Introduce a serializable structure. :-(<br>
><br>
>> What's your take on this? If we go the structure route, which information<br>
>> should this structure contain apart from the name?<br>
>> java.lang.reflect.TypeVariable also has the generic declaration information.<br>
>><br>
>> Do you foresee issues if we are not using java.lang.reflect.<wbr>TypeVariable?<br>
>> Typically it would be harder to do additional reflection things.<br>
><br>
><br>
> Yeah, as the generics model evolve, we might paint ourselves in the corner.<br>
><br>
>> = 2. Type argument constraints<br>
>><br>
>> So, the discussion above also applies to type argument constraints but<br>
>> there are some specific questions for them.<br>
>><br>
>> == 2.1 New node type<br>
>><br>
>> Type argument constraints cover the following case, ZipCode being a<br>
>> constraint:<br>
>> Map<@ZipCode String, String> map;<br>
>><br>
>> In this case, we envision the following node structure (assuming we would<br>
>> add the typeParameter discussed in 1.1):<br>
>> (name = map, type = property) -> (name = '<map key>', type =<br>
>> TYPE_ARGUMENT, isInIterable = true, key = myKey, typeParameter = K)<br>
>><br>
>> TYPE_ARGUMENT is a new type introduced in javax.validation.ElementKind.<br>
>><br>
>> Does it make sense?<br>
><br>
><br>
> My answer from above applies here as well.<br>
><br>
>> == 2.2 Default node names<br>
>><br>
>> The default extractors define the following node names for the added<br>
>> TYPE_ARGUMENT node:<br>
>> - arrays and Iterables (List included): <iterable element><br>
>> - Map key: <map key><br>
>> - Map value: <map value><br>
>><br>
>> This is similar to the nodes we created for "<return value>" or<br>
>> "<cross-parameter>" constraints.<br>
>><br>
>> Question: should they have a node name? should it be the type parameter<br>
>> name instead (so E or K or V for instance)?<br>
>><br>
>> Note that this might have consequences in the string representation we<br>
>> will discuss later.<br>
><br>
><br>
> If they must have a name, it will probably have to be named after the types<br>
> they apply to and type parameter order :-(<br>
><br>
>><br>
>> == 2.3 Optional and ObservableValue<br>
>><br>
>> In these 2 cases, we won't append a node.<br>
>><br>
>> Note that while in the ObservableValue case, it might feel more natural as<br>
>> the constraint will probably be used like:<br>
>> @NotBlank StringProperty property;<br>
>> to apply a NotBlank constraint on the wrapped value so it's rather logical<br>
>> to not have a node.<br>
>><br>
>> Just to be clear, for Optional, on the other hand, with our proposal, we<br>
>> won't have a node whereas the code looks like:<br>
>> Optional<@NotBlank String> optional;<br>
><br>
><br>
> Couldn't quite understand what comments I could make about it, so ok :-)<br>
>><br>
>><br>
>> = 3 String representation<br>
>><br>
>><br>
>> Note: this is implementation specific but we thought it might be<br>
>> interesting to discuss it here anyway.<br>
><br>
><br>
> Sorry, too many nuances and I don't have a strong opinion here.<br>
><br>
> Regards,<br>
> Michael<br>
><br>
</div></div>> ______________________________<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>
______________________________<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>