On Jul 13, 2012, at 10:48 PM, Sven Van Caekenberghe wrote:

On 13 Jul 2012, at 15:44, Marcus Denker wrote:

...

Issue 6356: some cleanups related to methods moved away from SmalltalkImage (vm and os related) http://code.google.com/p/pharo/issues/detail?id=6356

OK. but how can a poor library developer trying to write code that has to remain compatible with 1.3 and 1.4 deal with this ?

Have a look at

ZnUserAgentSettings class>>#platformDetails ^ self platform platformName, ' ', self platform platformSubtype, ' ', self platform osVersion

Now, this is a deprecated class in Zn as well, but rewriting

self platform osVersion

to

self platform os version

does not seem to give the same result in 1.4

Any suggestions ?

maybe we need to concept of pre-deprecation? Then we can pre-deprecate a method, and a version later deprecate it, and then remove it... In general: staying compatible forever means no change. That is possible, too. Marcus -- Marcus Denker -- http://marcusdenker.de

On 14 Jul 2012, at 00:08, Marcus Denker wrote:

We could just add a good version of #version to SystemPlatform in 1.4. Because what is called on 1.4 is #version of ClassDescription which is related to a concept of class versions which seems to be some arcane stuff in need of cleanup.

version "Return the version number string of the platform we're running on" "OSPlatform version"

^(Smalltalk vm getSystemAttribute: 1002) asString

I'll have another look, it is not that important in the scope of Zinc (and it is used in a Zinc deprecated class anyway). Sven

On Fri, Jul 13, 2012 at 10:47 PM, Sven Van Caekenberghe <sven@beta9.be>wrote:

On 13 Jul 2012, at 15:44, Marcus Denker wrote:

...

Issue 6356: some cleanups related to methods moved away from SmalltalkImage (vm and os related) http://code.google.com/p/pharo/issues/detail?id=6356

OK. but how can a poor library developer trying to write code that has to remain compatible with 1.3 and 1.4 deal with this ?

Last version of Fuel works from Pharo 1.1 to 2.0. What we do is to have "Compatibility packages" which are usually some overrides in a few methods. Fuel's "trunk" is CLEAN, as good as possible (no need of any backward compatibility) and expected to work in latest Pharo while all the rest is fixed in those overrides for those compatibility packages. For example, see ConfigurationOfFuel: spec package: 'FuelCompatibilityForSqueak' with: [ spec requires: #( 'FuelCompatibilityBeforePharo12' ) ]; package: 'FuelCompatibilityBeforePharo12' with: [ spec requires: #( 'FuelCompatibilityBeforePharo13' ) ]; package: 'FuelCompatibilityBeforePharo13' with: [ spec requires: #( 'FuelCompatibilityBeforePharo14' ) ]; package: 'FuelCompatibilityBeforePharo14' with: [ spec requires: #( 'FuelCompatibilityBeforePharo20' ) ]; package: 'FuelCompatibilityBeforePharo20' with: [ spec requires: #( 'Fuel' ) ]. The browse any of those packages to see what I mean. Maybe something like this can help you. Cheers

Have a look at

ZnUserAgentSettings class>>#platformDetails ^ self platform platformName, ' ', self platform platformSubtype, ' ', self platform osVersion

Now, this is a deprecated class in Zn as well, but rewriting

self platform osVersion

to

self platform os version

does not seem to give the same result in 1.4

Any suggestions ?

Thx,

Sven

-- Mariano http://marianopeck.wordpress.com

On Sat, Jul 14, 2012 at 9:31 AM, Sven Van Caekenberghe <sven@beta9.be>wrote:

Yes, a set of layered compatibility packages is a solution, but a lot of work to maintain. I guess.

From my little experience with Fuel, it was the *easiest* way we found. We just put the overrides in the compatibility packages. No need to think how to be compatible. You can also do a lot of dirty hacks, like registering stuff in Smalltalk globals (for classes that were removed) or to create subclasses from the originals with the names you need, etc....What I mean is that I don't care how "beautiful" these compatibility packages are (as said, they are usually dirty). All I care is that they work and that they let me have the real beautiful code in trunk.

I was trying to avoid that. With FileSystem there was no way around it.

You mean the class renames?

Thanks for the pointer.

Sven

On 14 Jul 2012, at 00:05, Mariano Martinez Peck wrote:

...

On Fri, Jul 13, 2012 at 10:47 PM, Sven Van Caekenberghe <sven@beta9.be> wrote:

On 13 Jul 2012, at 15:44, Marcus Denker wrote:

...

Issue 6356: some cleanups related to methods moved away from SmalltalkImage (vm and os related) http://code.google.com/p/pharo/issues/detail?id=6356

OK. but how can a poor library developer trying to write code that has to remain compatible with 1.3 and 1.4 deal with this ?

Last version of Fuel works from Pharo 1.1 to 2.0. What we do is to have "Compatibility packages" which are usually some overrides in a few methods. Fuel's "trunk" is CLEAN, as good as possible (no need of any backward compatibility) and expected to work in latest Pharo while all the rest is fixed in those overrides for those compatibility packages. For example, see ConfigurationOfFuel:

spec package: 'FuelCompatibilityForSqueak' with: [ spec requires: #( 'FuelCompatibilityBeforePharo12' ) ]; package: 'FuelCompatibilityBeforePharo12' with: [ spec requires: #( 'FuelCompatibilityBeforePharo13' ) ]; package: 'FuelCompatibilityBeforePharo13' with: [ spec requires: #( 'FuelCompatibilityBeforePharo14' ) ]; package: 'FuelCompatibilityBeforePharo14' with: [ spec requires: #( 'FuelCompatibilityBeforePharo20' ) ]; package: 'FuelCompatibilityBeforePharo20' with: [ spec requires: #( 'Fuel' ) ].

The browse any of those packages to see what I mean.

Maybe something like this can help you.

Cheers

Have a look at

ZnUserAgentSettings class>>#platformDetails ^ self platform platformName, ' ', self platform platformSubtype, ' ', self platform osVersion

Now, this is a deprecated class in Zn as well, but rewriting

self platform osVersion

to

self platform os version

does not seem to give the same result in 1.4

Any suggestions ?

Thx,

Sven

-- Mariano http://marianopeck.wordpress.com

-- Mariano http://marianopeck.wordpress.com