Re: [PROPOSAL] lifecycle release

Stefano Mazzocchi wrote:
> Stephen McConnell wrote:
> 
> Wasn't the proposal about migrating the lifecycle package into framework 
> or did I overlook something?

No it was about placing it in the "avalon" CVS repository, and
being maintained separately from Framework.

>> Can you be more specific - what in you view are the one-man shows that 
>> must stop? 
> 
> I don't see many people working on Merlin. Is this a wrong perception?

It will after we get the Unified Avalon release done.

>> Are these one-man shows related to released packages, packages 
>> scheduled for release, or are you referring to activities under the 
>> avalon-sandbox project.
> 
> I'm referring to Phoenix and Merlin. Both seem to me one-man-shows. But 
> hopefully I'm wrong.

Phoenix is actively maintained by more than one individual.  There are
some projects that depend on it so we also cannot just get rid of it.


>> Perhaps you could put forward you concrete arguments. Nothing below 
>> even suggests that you're familiar with the package in question. In 
>> fact several of the comments suggest that you may be confusing the 
>> lifecycle package with something else. You response on this is 
>> important because if you really think that the result of the 
>> collaboration between Marcus, Berin and myself is a "hack" - then I 
>> would like to discuss that will you. I will disagree with your 
>> position and present substantial evidence supporting that position. If 
>> however you comment is made with same level of indifference as the 
>> original hack comment from Peter Donald, then I can safely ignore it.
> 
> 
>  From there I stand:
> 
> 1) something is moving into avalon framework

That was a misperception.  That is not happening.

> 2) in my view of the world, this *something* is therefore going to be 
> considered *ROCK* solid

How about *next* to framework--but not *in* it?

>> The lifecycle package was a successful process of collaboration by 
>> three people each with relatively different ideas on the approaches 
>> concerning lifecycle stage management under the Avalon framework. 
> 
> I now see a forth disagreeing. This is valuable input from me.

Can I ask you a question?  How comfortable are you with the complexities
of interception?  It is not as simple and straight-forward as its main
proponent suggests.  In order for it to work effectively, we need to
use a dynamically generated approach which either means incorporating
CGLib or using Dynamic Proxies.

Either way, I haven't seen where the code is really more understandable
using interceptions than the proposed extensions standard.

Don't get me wrong, interceptions are a cool concept--if the user can
be successfully hidden from the implementation details.  We have not
had an opportunity to do that as a community yet.