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. Cheers -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx
