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 ...
Just a thought...
Dale
2010/10/11 Dale Henrichs dhenrich@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
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@gmail.com wrote:
2010/10/11 Dale Henrichs dhenrich@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Julian,
Makes perfect sense ... there's only so much that can be done with limited resources and backward compatibility is a thankless dirty job and there are real limits as to how far you can actually go in backward compatibility.
Now that I think a little bit more about this ... I suppose that creating backward compatibility packages would be something that the Pharo folks themselves should ultimately be responsible for and presumably if the demand is there, they will be created...
Thanks,
Dale
On 10/12/2010 01:30 AM, Julian Fitzell wrote:
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@gmail.com wrote:
2010/10/11 Dale Henrichsdhenrich@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@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
seaside-dev mailing list seaside-dev@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
On 10/11/2010 10:47 PM, Philippe Marschall wrote:
2010/10/11 Dale Henrichsdhenrich@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
seaside-dev@lists.squeakfoundation.org
-
Dale Henrichs -
Julian Fitzell -
Philippe Marschall