Re: [xwiki-devs] [PROPOSAL] Change component role from Class to Type

Hi guys, I'm almost done but there is one little detail left: for easier retro-compatibility I would like to introduce a new @Role annotation and deprecate the @ComponentRole annotation. The idea is that Role will "officially" take into account generic parameters while ComponentRole does not. That way no existing component role behavior will be broken or require crappy retro-compatibility like registering automatically both generic and non generic roles (what I started to do at first). On Thu, Mar 1, 2012 at 6:20 PM, Thomas Mortagne &lt;thomas.mortagne(a)xwiki.com&gt; 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. > > -- > Thomas Mortagne -- Thomas Mortagne