Stuart McCulloch wrote: > 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?
It uses the regular matching of mixin types to Composite types, so it's basically in registration order. > 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? Other way round: first check if there is a registered builder that has been explicitly provided with use(), and only if that has not been done will it check for Composite/Object. > this would be useful - a bit like Spring's "autowiring" feature. Sort of, yes! > 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 :) One major difference here, I think, is that we have the structure (app/layer/module with visibilities) to help us out, so there's less risk of such issues. The visualizer should also make it easier to deduce exactly what goes on given a specific assembly, so there's no need to "figure it out in your head". /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
