On Thu, Mar 1, 2012 at 18:20, Thomas Mortagne <[email protected]>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 DefaultStringDocumentReferenceResolver implements
> DocumentReferenceResolver<String>
>
> and
>
> @Component
> @Named("default/reference")
> public class DefaultReferenceDocumentReferenceResolver 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, Sounds good and it is effectively the right time to do so.
(by the way, a very clear explanation of the issue, great mail, pleasant to
read)
>
> --
> Thomas Mortagne
> _______________________________________________
> devs mailing list
> [email protected]
> 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
