On Apr 22, 2010, at 11:10 AM, Andreas Raab wrote: > On 4/22/2010 1:21 AM, Henrik Johansen wrote: >> 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.
Agreed. > >> 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. I know you remember I was in favor of your solution. > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
