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

[Julian Fitzell]

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
<philippe.marschall at gmail.com> 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.
>
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>