> 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... -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
