I have problems to understand why this would be not reasonable that people load a give kom version for seaside on squeak and one for seaside on pharo.
If you put too much constraints then do not cry after that squeak code is shitty because it is. On Feb 27, 2009, at 7:39 AM, Philippe Marschall wrote: > Michael Rueger wrote: >> Philippe Marschall wrote: >> >>>> There is actually on more method (attached) that we need to add to >>>> either Kom or Seaside to make Pharo and Squeak compatible on the >>>> API level. >>> Sorry but no, see previous posts. Have a look at Seaside2.8a1-pmm. >>> 583 >>> for what I would find acceptable. >> >> OK, can you explain how I should make Seaside work on both Pharo and >> Squeak? I spent two days figuring out a minimal set of changes that >> would not require doing some ugly hack testing for which underlying >> platform you are dealing with and you say that is not acceptable? You >> *want* ugly hacks? I don't understand... > > - Monkey patching either Seaside or Kom is not acceptable. We have > this > issue partially because Kom is monkey patching Squeak. > - Forking Seaside for Pharo is not acceptable. > - Relying on a forked Kom is not acceptable, we need to have a > consistent interface for Kom in both Squeak an Pharo. > > That kinda limits our options. > > Second the fix is not that ugly. It just sends #asString to > something it > expects to be a String. This is not a that uncommon idiom. And we > already have to do something way uglier for ensuring author initials. > > That's what happens if you break the API. You brake a lot of code and > cause a lot of pain for a lot of people. > > Cheers > Philippe > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
