Re: [picocontainer-dev] package renaming

Paul Hammant wrote:
>>> 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.
Now sure how that looked like, but if there was less inheritance 
involved then I think it is better.

>   MutablePicoContainer becomes PicoContainer
Yes! That's cool.
> But not on...
>
>   PicoContainer becomes 'Components'
That's actually quite elegant.
Components components = ...
MyTable t = components.getComponent(MyTable.class)

Erik