expand Grease to support portability between Pharo versions?

> 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 ...

> 2010/10/11 Dale Henrichs <[hidden email]>:
>> 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.
>
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>

> 2010/10/11 Dale Henrichs<[hidden email]>:
>> 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.

> Hi Dale,
>
> I've certainly considered it. It makes total architectural sense to
> have Grease 1.0 platform packages for, say, two different versions of
> Pharo (the two versions are, essentially, just two different
> platforms).
>
> As far as I'm concerned, anyone should feel free to implement Grease
> on any platform they desire (including old versions of any Smalltalk
> at all). There's a bit of a challenge with regards to naming and code
> management, but they can presumably be sorted out somehow. As Philippe
> says, though, backwards compatibility is a big pain and it's not an
> itch that I'm personally particularly interested in scratching.
>
> If we're talking about going beyond implementing Grease for multiple
> versions and instead extending the protocol of Grease, I start to have
> concerns (remember everything in Grease needs to be implemented on
> *every* platform). There's nothing stopping someone from building
> another layer that sits on top of Grease and provides added
> compatibility between Pharo versions, though, of course. I can't see
> any disadvantage to that approach over including it in Grease itself,
> and it keeps the mission statement of Grease simpler. No?
>
> Julian
>
> On Tue, Oct 12, 2010 at 6:47 AM, Philippe Marschall
> <[hidden email]>  wrote:
>> 2010/10/11 Dale Henrichs<[hidden email]>:
>>> 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.
>>
>> Cheers
>> Philippe
>> _______________________________________________
>> seaside-dev mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev