On 31 December 2010 12:45, Igor Stasenko <[email protected]> wrote: > On 31 December 2010 11:03, Nicolas Cellier > <[email protected]> wrote: >> On the other hand, if old packages are usefull, they should be >> maintained and upgraded. >> >> If Pharo wants to remove these deprecated methods, an alternative >> policy is to move deprecated methods in a separate backward >> compatibility package. >> > > +1 > I would call it 'Pharo-Cruft' > :)
Sorry for quick comment. I think this idea is userful to safely remove anything from system and it can be even automated Utilities moveDeprecatedToCruft "put all senders of #deprecated to '*Pharo-Cruft' category" ... Because a package author who wants to upgrade his package can be always sure that he can fix it, because he can use Pharo-Cruft for checking what removed methods was doing, and what is analogous functionality he can use in modern image (all deprecated methods should contain a comment describing, why it was removed and what should be used instead). Just removing methods, as it shown by this topic (isFinalizationSupported), could lead to unnecessary questions and confusion. > >> Nicolas -- Best regards, Igor Stasenko AKA sig.
