We could rollback and introduce a new message and deprecates the other. This is just that I do not have the energy for that. Now this is also important that we do not get bound to existing API for the sake of them. Stef
>> >>> ToolBuilder is one of the projects I believe deserve to stay fork-agnostic. >>> >>> Exactly how we should go about coordinating so they stay in synch I'm >>> interested in hearing :) >> >> That's not so difficult. Let's start by just merging the code bases, and see >> where this leads. I expect few, if any difficulties here. Let's add some >> test to document the changes (like the one Torsten was bitten by) and we >> should be pretty much covered. >> >> Further out, I don't expect us to stay closely in sync. The whole issue of >> upstream vs. downstream packages is an open one, so my opinion is that we >> should merge when it makes sense (i.e., new features being added) but >> otherwise let each project have its own choices. >> >>> With ToolBuilder, I also include the protocol of UIManagers. >>> In that regard, one of the changes I think would be hard to get "Pharoers" >>> to back down from, is the change of nil instead of '' return for request: >>> dialog cancels. >> >> What can I say ... I actually said in that discussion that the right choice >> is to introduce a different protocol, i.e., request:onCancel: or something >> similar. Now we'll end up with a new protocol anyways - I don't expect Pharo >> to change (too much pride involved) and I don't expect Squeak to change (too >> much legacy code involved) so a new protocol for the people who care about >> compatibility going forward is really the only option (which can also be >> back-ported if necessary). The end result will be that we'll declare the >> return value of #request: to be "undefined" if the dialog is canceled and >> recommend using the new protocol. >> >> It's a great lesson about how not to break an existing protocol. If Pharo >> had introduced a new protocol we could have just implemented it in Squeak >> and be done. Instead, the end result will be that a new protocol is >> introduced anyway and that nobody will be able to reliably use the the old >> protocol. Consider it a lesson for the next time an issue like this comes up >> - if you're interested in compatibility breaking an existing protocol isn't >> the smart choice, in particular when it comes to cross-platform / >> cross-dialect protocols. >> >> Cheers, >> - Andreas > No arguments from me, I strongly defended the approach you suggested at the > time. > Sadly, (in my eyes) discussion just died, and everything got changed anyways. > > Cheers, > Henry > > (Link to thread in question, for those interested) > http://smalltalk.1294792.n4.nabble.com/Fwd-Issue-1129-in-pharo-UIManager-request-and-multilineRequest-do-not-distinguish-between-empty-and-l-td1301670.html > _______________________________________________ > 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
