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
