2008/9/6 Rickard Öberg <[EMAIL PROTECTED]> > Hey, > > Currently @Uses requires that an object of the specified type is > provided to the builder when the Composite/Object is constructed. I > would like to modify this so that if no object is provided, then the > @Uses provider factory will 1) look for a Composite implementing the > requested type and 2) look for an Object implementing the requested type. >
sounds reasonable - what happens if there are multiple candidates? also, if there is no matching Composite/Object but there is a matching builder then should use that builder to create a new Composite/Object? > The reason for this is that I have a couple of cases where I want an > Entity or Service to depend on another Composite, but since neither of > them has a way to provide @Uses that other Composite must be a Service > itself. In the usecase I have (the Entity Serializer) it doesn't really > make sense, and it also makes it impossible for the user to customize > it, since the provided instance will be shared between all usages. > > Another consequence of this is that it becomes trivial to create > composite "trees" whereby if you instantiate a Composite that has @Uses > to another Composite, which has @Uses to a third Composite, that "tree" > is going to be resolved and created automatically, without having to > construct the Composites and provide them with CompositeBuilder.use() > manually. > this would be useful - a bit like Spring's "autowiring" feature. autowiring has had a bad press, as it can make it hard(er) to grok the XML - so most projects end up using explicit wiring. It will be interesting to see if "auto-uses" can avoid this :) /Rickard > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev > -- Cheers, Stuart
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
