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