On Wed, Apr 4, 2012 at 20:00, Vincent Massol <[email protected]> wrote:
> Hi Thomas/All, > > All looks good except CM.lookupComponent() which Ï don't like a lot for > the following reasons: > * It's a bit long. It's longer than before and it would be nicer if it > were as short as before or even shorter ;) > * It's not symmetrical with other lookups like lookupList and lookupMap, > which should theoretically be lookupComponentList() and > lookupComponentMap() which are even longer > > Thus I'd prefer that the new API for lookup be named differently. > > I propose to use "resolve": > > CM.resolve(Type) > CM.resolveList(Type) > CM.resolveMap(Type) > -0 > > Alternative: > > CM.getInstance(Type) > CM.getInstanceList(Type) > CM.getInstanceMap(Type) > +1 > > or even the short: > > CM.get(Type) > CM.getList(Type) > CM.getMap(Type) > +0 > > For information Guice uses getInstance(), Picocontainer uses > getComponentInstance(). > > WDYT? > > My preference goes to getInsta nce(): > * users are tempted by default to start typing "get" to get an instance > and then they'll see getInstance in autocompletion and choose it. > * it's the same as Guice > > Thanks > -Vincent > > On Mar 6, 2012, at 2:51 PM, Thomas Mortagne wrote: > > > 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 > > _______________________________________________ > 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
