Re: [picocontainer-dev] package renaming

>> The old DPC tried too much. On one hand we tried to set it up, how we
>> thought Pico should be used and on the other hand we tried to make  
>> it so
>> flexible that you could change almost anything. So my advice is:  
>> Split it
>> up!
>> Create an abstract PC implementation that provides the flexibility  
>> and
>> derive from it the specialized, but now inflexible container and  
>> name it
>> properly. Now every can have a look why the container is setup in  
>> this
>> special way and create easily an own one, if the one we deliver  
>> (or the
>> ones we deliver) does not match any of the needs.
>
> +1

OK, I've deleted the contentious containers. I always intended to,  
after making NanoContainer extent MutablePicoContainer (and reuse  
methods).

Here is the list of implementors of MutablePicoContainer :-

     DefaultPicoContainer implements MutablePicoContainer
     DefaultNanoContainer implements NanoConatiner (which extends  
MutablePicoContainer) and delegates to a DefaultPicoContainer instance
     CommonsLoggingTracingContainerDecorator
     Log4JTracingContainerDecorator

That's it, there are no others :-)

If we go back to a composed DefaultPicoContainer (that's what the  
first alphas of Pico we're back in 2003), then I'm cool with that.

The obvious way to do it is have something that implements all the  
methods of PicoContainer, and something that implements all the other  
methods in MutablePicoContainer and delegates to the first.

I'm also keen to do renames.  With Pete in the bar on Friday, we  
agreed on ....

   MutablePicoContainer becomes PicoContainer

But not on...

   PicoContainer becomes 'Components'

ComponentSet ?
ComponentList ?

- Paul

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

    http://xircles.codehaus.org/manage_email