Re: [picocontainer-dev] Creating New Containers

Can the start/stop veto logic move into the lifecycle impls? And out  
of DPC?

Sent from my iPhone

On Dec 3, 2007, at 10:23 AM, "Michael Rimov" <[email protected]>  
wrote:

> Hi All,
>
> I have an extension question:
>
> I'm interested in hacking together a new type of PicoContainer that  
> has a
> modified lifecycle behavior: the container is startable again once  
> dispose has
> been called.  (As to why I'm doing this, I'll talk about it more  
> once I prove
> the result to myself in test cases :D )
>
> However, this desired behavior is wrought with difficulties:
>
> 1 - DefaultPicoContainer will throw an Exception if start() is ever  
> called
> multiple times.  So the delegating Mutable Picocontainer won't help  
> here.
>
> 2 - Changing start() and stop() locally won't work because the  
> implementation of
> DefaultPC relies on several data structures that are inaccessible.
>
> So, it seems that my current options are:
>
> 1 - Copy and paste a lot of code from DPC.  (Obviously an Anti- 
> Pattern!)
>
> 2 - Make the lifecycle variables in DPC have protected getters/ 
> setters and
> modify them from a class derived from DefaultPicoContainer. (Sounds  
> like a
> slightly less anti-pattern than option #1)
>
> 3 - Make a class  (or multiple classes) and move most of the DefaultPC
> implementation capabilities into that class.  Then utilize that  
> class in both
> PicoContainer's and MyPicoContainer.
>
> #3 seems like the best choice, but I'm concerned about mucking about  
> with
> other's (namely Konstantin's!) current work as well as destroying  
> the integrity
> of DefaultPicoContainer by exposing too much underlying data.   
> (Although by
> moving that part to a separate class, in a way we're preserving DPC)
>
> Anybody have any thoughts on this?
>                                    -Mike
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list please visit:
>
>    http://xircles.codehaus.org/manage_email
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email