Glenn R. Golden wrote:
If anyone cares to comment on the Pico v.s. Avalon Framework question, I'd be happy to listen.
The good idea in Pico is the leverage of existing meta information available in a class Constructor definition. From this information a container can derive type based dependencies and from this the infurance of assembly logic and deployment sequencing. That single characteristic has some particular advantages related to the java language and some immediate advantages (and dangers) with respect to simplicity of demonstration.
At the java language level you can write a component and leverage final variables that are assigned at the time of instantiation. This is a really positive point as it enables a higher level of compile time checking (i.e. you get error concerning non-assignment or attempted reassignment of variables). This means the component implementation code tends to be better checked that code uising non-final variable assignments.
The bad idea in Pico is to focus too much on the good idea because the good idea is an of itself is only part of the complete picture. Where things become interesting is the potential with Avalon container solutions (e.g. Merlin) to incorporate ideas that have been validated by Pico concerning constructor as the vehicle for passsing of container generated artifacts, but in a way that is consistent with our current approach, while maintains and leveraging meta info and meta data. One approach I have been looking at it to provide classic artifacts via constructor and thereby eliminating the obligation on the client to implement interfaces such a LogEnabled, Configurable, Contextualizable, Serviceable, etc.
For example - current scenario:
public class MyComponent implements Configurable
{
private Confiuration m_config; public void configure( Configuration config )
{
m_config = cofig;
}
}As compared with:
public class MyComponent
{
private final Configuration m_config; public MyComponent( Configuration config )
{
m_config = config;
}
}In the first case there is the implicit no-argument constructor and the explicit existance of Configurable indicating the the component is configurable. The second example eliminates that aspect of intrusion on the developer and adds the benefit of final state members.
However, the usage of constructor info alone to resolve dependency information is IMO a bad thing to do because it eliminates an intermidiate artifact (a ServiceManager) that can provide greater flexibility in that a component can notify a container via the manager that it is not longer consuming the resource. Secondly, the usage of managers and meta data elnable the postential for component suspension and resumption cycles during which content of a manager is updated behind the scenes consitent with meta-info supplied by the component type.
Hope that helps.
Cheers, Steve.
Thanks.
- Glenn
Glenn R. Golden CHEF Architect System Research Programmer III School of Information + Media Union @ University of Michigan [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
