+1
On Mon, Mar 5, 2012 at 19:28, Sergiu Dumitriu <[email protected]> wrote:
> On 03/01/2012 12:20 PM, Thomas Mortagne wrote:
>
>> Hi devs,
>>
>> I recently modified component manager internals and changed the role
>> used as key in the map from Class to Type so that it properly make a
>> difference between Provider<Toto> and Provider<Titi> without the need
>> to generate a special hint.
>>
>> For the one not aware of what Type is lets say it's what Class is
>> extending. Among other things Type is also extended by
>> ParameterizedType which is interesting here because it basically
>> contain a Class with it's generic parameters (it also indicate if the
>> type in included in another one but we don't care in our case ;)).
>>
>> To summarize:
>> * Provider is a Class
>> * Provider<String> is ParameterizedType
>> and both are Type
>>
>> That said I would like to change the whole ComponentManager and
>> related descriptors APIs to use Type as role instead of Class.
>>
>> = What it bring
>>
>> What it means is that it makes possible to cleanly represent a
>> Provider in which the generic type is meaningful right in the
>> ComponentDescriptor (right now the generic type is extract from the
>> implementation class when the provider is registered which is pretty
>> crappy) and simplify a lot the current implementation.
>>
>> But it also mean we could use this new "feature" for other components.
>> For example right now we have things like:
>>
>> @Component
>> public class DefaultStringDocumentReference**Resolver implements
>> DocumentReferenceResolver<**String>
>>
>> and
>>
>> @Component
>> @Named("default/reference")
>> public class DefaultReferenceDocumentRefere**nceResolver implements
>> DocumentReferenceResolver<**EntityReference>
>>
>> and injected by
>>
>> @Inject
>> DocumentReferenceResolver<**String> resolver;
>>
>> and
>>
>> @Inject
>> @Named("default/reference")
>> DocumentReferenceResolver<**EntityReference> resolver;
>>
>> Having Type used as role means that we could have:
>>
>> @Inject
>> DocumentReferenceResolver<**String> resolver;
>>
>> and
>>
>> @Inject
>> DocumentReferenceResolver<**EntityReference> resolver;
>>
>> = What it breaks
>>
>> So what's the catch ?
>>
>> Basically it would break any code that currently programmatically
>> register or unregister Provider since It would remove the current hack
>> to discover the Provider parameter (assuming that the
>> ComponentDescriptor now provide the complete role). But that's OK IMO
>> given that Provider support is very recent and I doubt it's a common
>> use case.
>>
>> We would obviously keep and deprecate all the existing APIs based on
>> Class which are pretty easy to implement since Class extends Type.
>> Even if removing them would not cause any issue when you build it's
>> not binary compatible since it's not the same method signature.
>>
>> So WDYT ?
>>
>> Here is my +1 and since we are starting a new major version it sounds
>> a good occasion so introduce such change.
>>
>>
> +1.
>
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/
>
> ______________________________**_________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/**mailman/listinfo/devs<http://lists.xwiki.org/mailman/listinfo/devs>
>
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
