[Pharo-project] Comments/suggestions on deprecations etc
Hi All, I'm seeing some unexpected behaviour with deprecations in 1.4. For example, if I do the following: Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSeaside30'; load. ConfigurationOfSeaside30 load. Deprecation raiseWarning: false. ZnZincServerAdaptor startOn: 8080. [ ZnEasy get: 'http://localhost:8080/status' ] fork. I get a deprecation warning, despite (I thought) having explicitly turned them off with "Deprecation raiseWarning: false". I think the underlying issue is that a "Deprecation" is always signalled, regardless of the state of "Deprecation raiseWarning", and the actual processing of e.g. logs, transcript, etc is deferred to "defaultAction". This makes side effects somewhat unpredictable when intermediate code catches Warning exceptions (from which Deprecation inherits). I think the fix is to not signal exceptions when raiseWarnings is false. A similar problem happens with unit tests which call deprecated code. These tests fail silently when "Deprecation raiseWarning" is false as "TestResult>>runCase:" catches the Warning exceptions. I think they should pass. It's seems useful to have the tests fail when raiseWarning is true. For myself, I've just moved the contents of "Deprecation>>defaultAction" into "Deprecation>>signal" with the obvious adjustments. I'm not sure this is necessarily the best way. Would appreciate any comments, conclusions etc from folks that know more about this stuff than me :) Cheers, Martin
Martin, On 10 Apr 2012, at 00:50, Martin Sandiford wrote:
I'm seeing some unexpected behaviour with deprecations in 1.4. For example, if I do the following:
Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSeaside30'; load. ConfigurationOfSeaside30 load. Deprecation raiseWarning: false. ZnZincServerAdaptor startOn: 8080. [ ZnEasy get: 'http://localhost:8080/status' ] fork.
Apart from your question, the goal of deprecations is to encourage people to use a different API. What deprecation did you actually get in that code ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Hi Sven, No argument about the need to change, and the deprecations themselves are pretty easy to correct by following the deprecation notices. I've found the following by clicking through the various tabs. SmalltalkImage>>isRunningCog moved to VirtualMachine class. Similarly for getSystemAttribute: and getVMParameters (now getParameters). All of these are in Seaside WA*Status classes. I guess the underlying change in the API would be something the Seaside folks would need to deal with at some point. My comments were more philosophically asking the asking the question about whether it should be possible to avoid the exception altogether --- it's sometimes awkward to require that all software be brought up to the same API baseline simultaneously. Cheers, Martin On Tue, Apr 10, 2012 at 6:10 PM, Sven Van Caekenberghe <sven@beta9.be> wrote:
Martin,
On 10 Apr 2012, at 00:50, Martin Sandiford wrote:
I'm seeing some unexpected behaviour with deprecations in 1.4. Â For example, if I do the following:
Gofer it   squeaksource: 'MetacelloRepository';   package: 'ConfigurationOfSeaside30';   load. ConfigurationOfSeaside30 load. Deprecation raiseWarning: false. ZnZincServerAdaptor startOn: 8080. [ ZnEasy get: 'http://localhost:8080/status' ] fork.
Apart from your question, the goal of deprecations is to encourage people to use a different API. What deprecation did you actually get in that code ?
Sven
Thanks we will discuss this point with esteban and igor.
I think the underlying issue is that a "Deprecation" is always signalled, regardless of the state of "Deprecation raiseWarning", and the actual processing of e.g. logs, transcript, etc is deferred to "defaultAction". This makes side effects somewhat unpredictable when intermediate code catches Warning exceptions (from which Deprecation inherits). I think the fix is to not signal exceptions when raiseWarnings is false.
A similar problem happens with unit tests which call deprecated code. These tests fail silently when "Deprecation raiseWarning" is false as "TestResult>>runCase:" catches the Warning exceptions. I think they should pass. It's seems useful to have the tests fail when raiseWarning is true.
For myself, I've just moved the contents of "Deprecation>>defaultAction" into "Deprecation>>signal" with the obvious adjustments. I'm not sure this is necessarily the best way.
Would appreciate any comments, conclusions etc from folks that know more about this stuff than me :)
Cheers, Martin
participants (3)
-
Martin Sandiford -
Stéphane Ducasse -
Sven Van Caekenberghe