It's committed. Would be nice to have comments on the new APIs (suggest better naming, etc...). It's a very important API and we really need to have something we are sure of before 4.0 final.
On Mon, Mar 5, 2012 at 6:53 PM, Thomas Mortagne <[email protected]> wrote: > 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 > <[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. >> >> -- >> Thomas Mortagne > > > > -- > Thomas Mortagne -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
