On Fri, Dec 31, 2010 at 11:50 AM, Guillermo Polito < guillermopolito@gmail.com> wrote:
Oh, come on...
Levente, we all agree with you. Pharo is trying to use that deprecation policy since some months ago... Sometimes people make mistakes (me included) and don't do it, but we agreed that we have to deprecate and remove after two versions of being deprecated.
I'm tired of this stupid arguments.
I expect the new year will bring us more doing and less discussing :).
Unless we are prepared to discuss, discover, admit and correct our mistakes our doing will be of little worth. I don't see anything stupid in discussing deprecation policy. This criticism of Levente is entirely unjustified and reminds me of recent treatment of certain prominent whistle-blowers. Can we just drop the childish feelings of hurt, and direct ourselves to the substance of arguments rather than our immediate emotional reactions to email? We should all know by now that email is a particularly inexpressive medium, prone to misinterpretation and therefore it behooves us to take a breath before we reply and try and read beyond our surface perceptions. [I am a hypocrite in this regard having over-reacted recently over timestamps.] Doubtless we are all imperfect in our use of email and can all do better here. But we won't get any better by lacking objectivity and reacting emotionally to valid criticism. Can we make one of our new year's resolutions an attempt to be less emotional and more objective in all our email discussions in the broader Squeak community? Please? Happy New Year Eliot
2010/12/31 Levente Uzonyi <leves@elte.hu>
On Fri, 31 Dec 2010, Miguel Cobá wrote:
El vie, 31-12-2010 a las 20:05 +0100, Levente Uzonyi escribió:
What you describe here is simply bad practice. One should run the tests before deploying code (besides testing the complete system thoroughly). If you use RFB, you can access the GUI in headless mode. Also when a debugger opens with a deprecation warning, the stack trace is written to the log file, so you will be notified about the problem even when you don't have access to the GUI.
Yeah, sure. But if it a second level dependency (a package I use that uses a package that contains popups deprecation warnings) I have big chances of being bite by this problem. I concede, this could be avoided by test-running every and whatnot package in the image but for a system that updates automatically this will bite.
So you're saying that it's better to get a DNU instead of a deprecation warning with proper description about what and how to update/change?
Levente
Also, even if I can use RFB or read the image logs, I most likely will
monitor the application logs and will pass a time without me knowing that some part of the application is waiting some user input. At the end I expect that the maintainer of the package is the *responsible* of test the application for the image I use, and not the user of the package. That is what I do with magma on Pharo. I test and fix the issues generated by the evolution of Pharo and then I release a new ConfigurationOfMagma that the user can use without knowing that n deprecations were involved in the upgrade of the package.
Anyway, there's no reason to remove a method (especially an API method) without deprecating and keeping it around for a few releases.
I agree that is better to not forget to mark some method as deprecated but, again, I think that this promote the external packages not being updated to the current pharo image.
Cheers
-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx