On 10 févr. 2012, at 23:24, michael keith wrote:
>
>> What about attributes that have a subtype of X? If we allow subtypes, which rules do we have for "specialization"?
>> Do we reuse the overloading rules of the JVM? What about potential conflicts, is that an exception at deployment time?
>
> Yes, I have flip-flopped on the specialization question. I can think of a case or two where it would be nice for a converter to apply to all attributes of all subclasses of the target type, but I can also see cases where it would be a pain if that were true. Some obvious options, here, are:
>
> 1) Restrict it to the exact type
> 2) Apply it to all subclasses
> 3) Apply it to all assignable types
>
> If we decide it is worthwhile either now or at some point in the future to support more than one of 1), 2) and 3) then some ideas are to:
>
> a) Make autoApply an enum type, with values of TargetClassOnly, ... (whatever options we think are worthwhile)
> b) Make autoApply an internal annotation with separate elements that can be filled in with additional options/rules now or later
> c) Add an additional element to @Convert (yuck) to add more information (e.g. the set of classes to apply it to if autoApply is true)
I like option a.
>
>>> * unless overridden by means of the Convert annotation (or XML equivalent).
>>> * In determining whether a converter is applicable to an attribute,
>>> * the provider must treat primitive types and wrapper types as equivalent.
>>> *
>>> * Note that Id attributes, version attributes, relationship
>>> * attributes, and attributes explicitly annotated as Enumerated
>>> * or Temporal (or designated as such via XML) will not be converted.
>>> *
>>> * If autoApply is false, only those attributes of the target type pair
>>> * for which the Convert annotation (or corresponding XML element) has
>>> * been specified will be converted.
>>> *
>>> * The behavior is undefined if there are two converters defined for
>>> * the same target types and the Convert annotation is not used
>>> * to explicitly specify use of a converter.
>> I'd rather have an exception here. Any reason to leave it undefined?
>
> Just in case providers wanted to adopt their own rules for converter precedence.
> I have no problem with an exception, here, though. I expect most providers would throw one, anyway.
Can any implementation that would like custom rules here speak up? I'll try and think about it on my side. We could also make it an open question on the first draft to gather feedback.
>
>
>>> The Convert annotation is used to specify the conversion of a Basic
>>> (whether explicit or default) field or property. The Convert annotation
>>> should not be used to specify conversion of the following:
>>> Id attributes, version attributes, relationship attributes, and attributes
>>> explicitly annotated (or designated via XML) as Enumerated or Temporal.
>>> Applications that specify such conversions will not be portable.
>>>
>>>
>>> The Convert annotation may be applied on a basic attribute or
>>> an element collection of basic type (in which case the converter
>>> is applied to the elements of the collection). In these cases, the
>>> attributeName element must not be specified.
>> So that excludes the possibility to convert a collection object into a flat representation in String. do we want to cover this use case?
>> I'm tempted to say that's a fair use case.
>>
>> A way around that would be to make use of the attributeName to decide whether or not the collection itself or its elements are targeted. That has the benefit of rendering @Convert(attributeName="key") symmetric with @Convert(attributeName="value") (example below).
>
> Yes, Gordon's suggestion seems to be a simple way to achieve that.
Yes, I had not realized that option.