Hey,
I just finished a major runtime refactoring. Basically, the algorithm
for doing module traversal for lookups etc. used to be spread out over
tons of methods, as each usecase repeated the rules ("look in module,
then in layer, then in used layers, don't allow ambiguous lookups"). Now
it is implemented once, using the visitor pattern.
Module/Layer/UsedLayers have methods for implementing it, and each
algorithm then simply implements a visitor that does its specific thing.
This change cut a LOT of code away. It also opened up for easy caching
of the lookup results (e.g. "Composite type lookup of Some in Module A
resulted in SomeComposite"), as the executed visitor trivially provides
a cacheable result. This can give us a significant performance boost in
some cases.
In doing this change I also noticed a number of algorithms which first
did a model search and then essentially repeated it in the instance
level of the runtime. With the visitor approach this is no longer
necessary, increasing performance even more.
I have also refactored service dependency lookups so that they are
really done upon model binding and not at instance injection at runtime.
At injection time the precalculated result is just applied, giving quite
nice performance to the whole process.
Since the @Service dependency lookup is now done in the model it opens
up for showing this information in Envisage! Envisage already has the
DependencyDescriptor, so it is mostly a matter of what information it
should be able to extract from the dependency model. The simplest would
be to just get the service identity (i.e. a string) and show this. If
the user wants to traverse it, then Envisage would have to find what
service corresponds to that service id. A little work, but not much.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
