On 2010-09-29 17.04, Stanislav Muhametsin wrote:
Let's try with practical example. Let's say we have a role X. Then, we have object of type Y, which also extends role X. Then we have a different object Z, which also extends role X. So which object of those should be mapped for X? They are different instances of object after all. Should the context know to map one of them to X, and not to map another to X? Otherwise the latter mapping will overwrite the former.
This is the responsibility of the system code that gathers the selected objects and instantiates the context. If the constructor in the context is used it is very simple (put right object in right parameter), whereas with injection the injector has to deal with it. The context only holds the selection and allows interactions to be fired off with that selection as a given rather than as parameters.
In Streamflow this is done by the REST API. In an upcoming version I have completely separated the lookup/mapping of objects to roles and the actual context. Right now these two are mixed, which is not nice.
Because I have many other projects using same kind of pattern for Typeable. Additionally to API interface of Typeable, there are three very useful classes in SPI, one containing basis for Typeable implementation, and two for reliable, customizable mapping for each API type and interaction. Now, whenever something changes in those three classes, I'd hate to need to copy changes to all of my projects using this pattern.
See your point, but it still sounds a bit weird to bring in a DCI framework to get access to Typeable, if you see what I mean.
/Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
