avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: Definition of IoC (was Re: [proposal] IoC type 3.14 extension to the Avalon Framework)
Date Tue, 18 Nov 2003 18:32:48 GMT
Ulrich Mayring wrote:
> Berin Loritsch wrote:
>> The choice of how to apply IoC is a matter of taste in many cases.  If
>> everything is passed in the constructor, then we have a more atomic 
>> construction phase.  But in reality no component is used until after the 
>> construction phase.
> Yep, but you have no control over the order in which the lifecycles 
> Compose, Configure, Initialize, Contextualize etc. are called. 

depending on how you look at it...you have control using 'type 3', and 
you don't have control (its dictated by the framework semantics) using 

> Everything is collapsed within the constructor and it is assumed that 
> the order of construction is irrelevant.

I would say that it is assumed that the component itself will ensure 
correct order of construction, if any is required.

> However, it does make a difference whether you initialize an 
> unconfigured component or configure an uninitialized component. For 
> example, a component that accesses an external resource might need a 
> username/password before it can do that. So it is vital that this 
> component passes through configuration before initialisation.
> Of course it is possible to maintain the correct order in a constructor, 
> but it cannot be guaranteed anymore. The component itself decides.

mind you, that is the case with avalon as well:

class MyComponent implements Configurable
   public void configure( Configuration config )
     new Thread( getNewWorker() ).start; // quite possible. Wrong, but
                                         // possible
     m_val = config.getChild("blah").value();

in terms of security, its best to look at the avalon lifecycle as a 
convention, not as something which is enforced. It is not enforced. 
There is no guarantee.




To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message