Re: [Question] ToolBuilder in Squeak 4.1 and Pharo 1.0 compatible?

> On 4/21/2010 4:32 AM, Hannes Hirzel wrote:
>> A question: Art the ToolBuilder in Squeak 4.1 and Pharo 1.0 the same?
>> Or if there is a difference what is the impact of it?
>>
>> Or put the question in another way. If I code an UI using the
>> ToolBuilder in Squeak 4.1 will it run in Pharo?
>
> They are mostly the same but not identical. If there is interest in the Pharo community we should merge the versions upstream in http://www.squeaksource.com/ToolBuilder.html (contact me if you're interested).
>
> Cheers,
>  - Andreas

> 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.
>
>> 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

>>
>>> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project