On Fri, 31 Dec 2010, Miguel Cobá wrote:
El vie, 31-12-2010 a las 17:18 +0100, Levente Uzonyi escribió:
On Fri, 31 Dec 2010, Miguel Cobá wrote:
El vie, 31-12-2010 a las 10:22 +0100, Levente Uzonyi escribió:
On Thu, 30 Dec 2010, John McIntosh wrote:
Well the question as pointed out was does this vm support weak object finalization? and since all closure vm support finalization, then asking the question was mute, so it was ditched. Sophie from the 2003 era had to ask.
The need for the check it outdated, but the method is still sent by external packages. With proper deprecation policy the method would be still available. It would simply return true and raise a deprecation warning.
But having a deprecated existing method also encourage to never update the external packages, so old bits are floating around even if not needed. Given the refactoring-mindset of the smalltalk community I'd say
You're right, those popups with the deprecation warnings are really encouraging people to not update the code. And who would give a damn about the deprecation message anyway? It's better to guess why things don't work or ask someone else (list).
Of course it is better. A pop up can be in some code path that only seldom is executed. For someone loading the code, no warnings means that everything is ok. Suppose they install it on a server side image thinking that everything is ok. Then sometime after that, the image stops working because the headless mode can't allow to see the popup that is waiting for someone to press a button. Again, the GUI is good sometimes, but sometimes is better to fail earlier. If on loading it doesn't load because of some missing method, the user can see right there that something is wrong with the package is trying to use.
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. Anyway, there's no reason to remove a method (especially an API method) without deprecating and keeping it around for a few releases. Levente
Cheers
-- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx