[Pharo-project] [update 2.0] #20209

Mariano Martinez Peck marianopeck at gmail.com
Sat Jul 14 05:08:05 EDT 2012


On Sat, Jul 14, 2012 at 9:31 AM, Sven Van Caekenberghe <sven at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120714/4cea2758/attachment-0001.html>


More information about the Pharo-dev mailing list