RE: [RT:A5] What are the _real_ concern areas?

> From: Peter Donald [mailto:[email protected]]
> >
> > Where would start(), stop(), suspend(), resume() and re*() 
> fit into this? 
> 
> start() collapses into init()
> stop() collapses into destroy()
> 
> suspend/resume + re* continue to be academic discussion 
> points that have yet 
> to be well implemented.

I'm not resonating with that.


> > How about lifecycle extensions?
> 
> What about them?

We need flexible lifecycle still.


> > I'm not sure that collapsing information delivery into a 
> single lifecycle
> > method, means we have to throw away all the remaining 
> lifecycle methods.
> > Maybe we should.  Maybe we shouldn't.
> 
> The most important thing about a framework is consistency. If 
> we are going to 
> remove SOC from lifecyle then we should do it consistently 
> and remove it from 
> all lifecycle. A splissplodge framework is much worse than no 
> framework.

No, striking the right balance between Separation of Concerns
and Fragmentation of Concerns is what is best.


> It basically comes down to whether you want fine grain components or 
> monolithic components. Avalon/Framework does fine grained and 
> thus allows a 
> lot broader range of applications and more intelligent 
> containers. However 
> monolithic containers are much easier to program to. 

I still want Avalon to work with fine grained components.


> ie The container can detect if object is configurable and if 
> it has a Relax 
> schema defined. If it does not then I can warn the user that 
> they should 
> define one. This ability is lost under the monolithic approach. Some 
> component types also explicitly allow some lifecycle stages 
> (ie Loggable) but 
> disallow others (ie Serviceable/Composable or 
> Configurable/Parameterizable). 
> This would not really be doable under the monolithic system 
> except by return 
> null.

Or throw a NotBoundException...