[Seaside-dev] expand Grease to support portability between Pharo versions?

Dale Henrichs dhenrich at vmware.com
Tue Oct 12 17:14:40 UTC 2010


On 10/11/2010 10:47 PM, Philippe Marschall wrote:
> 2010/10/11 Dale Henrichs<dhenrich at vmware.com>:
>> Julian,
>>
>> Have you considered that Grease could be used to ease porting applications
>> between Pharo versions?
>>
>> As Pharo moves forward older versions of Pharo will have the same
>> portability issues that exist between different dialects of Smalltalk...
>>
>> The portability issues that I've seen are not fundamental issues, but
>> peripheral issues like Preferences and the required use of 'Smalltalk os'
>> and 'Smalltalk globals' as the object behind the Smalltalk global has
>> changed it's class...
>>
>> In my mind the reason for making the changes are certainly good ones, but
>> from a backward compatibility perspective they create "silly portability"
>> problems like we've just had that keep a perfectly good project from running
>> on older versions of Pharo, just like they cause portability headaches for
>> folks porting that code to another dialect (I have yet to add #globals and
>> #os to my Smalltalk poxy class:).
>>
>> If these changes were included in Grease it would mean that folks with a
>> portability problem, could load Grease and address the handful of obvious
>> known problems ...
>
> Not too eager to do this:
>   - AFAIK Pharo has a policy of deprecating stuff for two releases
> before removing it.
>   - Seaside has a policy of deprecating stuff for one release before removing it.
>   - When you move to a new Seaside version you're IMHO likely to move
> to a new Pharo version as well because that's probably less effort
>   - Providing backwards compatibility is a major PITA, limits you
> severely in the changes you can make and is a lot of effort. I see how
> this is valuable to companies so they don't have to keep their code up
> to date. But that's why such services and usually provided for money.

Philippe,

Understood ... I'm mainly thinking about folks that commit their data to 
a particular vm version and then get stuck in the past and are on their 
own for getting bugfixes and the like on their ancient, 1 year old 
application ... SqueakSource is a prime example and so is GemSource for 
that matter (GemSource is running Seaside2.6).

I honestly don't know how big of a problem it is now or how big of a 
problem it will become in the future.

Thanks,

Dale


More information about the seaside-dev mailing list