Re: [picocontainer-dev] Pico2 Deprecating old Names (Was: Pico2 releasing it ... before starting work on Composer 1.0)

Michael Rimov wrote:
>>> Can we aim at releasing Pico2 more or less as is?
>> Before I think one thing we should add back into the Pico and Mutable Pico
>> are
>> the old function names registerComponentInstance, etc etc etc and have them
>> marked deprecated (with javadoc pointing to the new method name)
>>
>> It should help people migrating a great deal.
> 
> Ugh, sorry Mauro, I must have deleted your reply to me....
> 
> I can understand that @Deprecations can cause problems in the future, but I find
> that:
> 
> 1 - When I dump in a new version of an opensource project, and all I get are a
> ton of compile errors, I tend to give up on that project (at least for the time
> being).  Deprecation errors at least give me an idea of where I need to start
> looking.  [I totally understand that given the current pico that we aren't
> trying to be 100% backwards compatible -- that said, if we can at least hit the
> 80% mark, I think it will help our community keep up with the rest of us.]
> 
> 2 - When something fails, I don't necessarily know where to look to figure out
> where to start changing my code.  By having deprecations, the compiler is
> pointing me in the direction of where to look (the javadocs).
> 
> 3 - In my experience, having one version that has deprecations and dumping them
> at the next version after that. (ie composer will have all deprecations dumped)
> seems to pay off with the project's users as well as increase communication with
> those contributors that aren't quite so active as you guys. 
> 
> Of course, as always, I won't roll on the ground kicking my feet and screaming
> if everyone decides they don't want to mess with it, but I'll be happy to add
> the interface deprecations myself and take responsibility for them.
> 
> 

I understand the intent - I'm just questioning which is the most 
sustainable approach, beyond the short term.

I think that the drop-in replacement paradigm with deprecation would 
work better with minor version upgrades, not necessarily such a major 
overhaul of the interface, and of the JDK features used.

Trying, as always, to find the LCD solution, I was thinking we could 
introduce a LegacyPicoContainer interface which extends 
MutablePicoContainer (and corresponding impl) that contained the old 
deprecated methods.   But the user would have to instantiate the legacy 
container to have the deprecations.

Mind you, I'm not going to roll and scream either :-) I'm happy to go 
with majority.

Cheers


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

    http://xircles.codehaus.org/manage_email