I agree with andreas point. :) Begin forwarded message:
From: codesite-noreply@google.com Date: September 29, 2009 6:31:41 PM GMT+02:00 To: stephane.ducasse@gmail.com Subject: Issue 1129 in pharo: UIManager #request: and #multilineRequest do not distinguish between empty and cancel
Comment #22 on issue 1129 by andreas.raab: UIManager #request: and #multilineRequest do not distinguish between empty and cancel http://code.google.com/p/pharo/issues/detail?id=1129
I'll give it one last shot: From my perspective, the problem is not how difficult it is to fix it, the problem is that there is a change in semantics of a widely deployed method that affects every single place that uses it. I could follow your reasoning more easily if the situation where such that for 80% of the users everything stays the same but the change you are proposing necessitates that every single place that uses these methods needs to be changed. And not being able to tell whether a particular place has been fixed or not is just bad engineering since you are making it strictly harder for your users to determine whether they still need to do something for addressing this issue or not. That's what deprecations are for - telling users that there is something they need to take care of.
I think that the change you are proposing is a decidedly bad choice and urge you to reconsider for the following reasons:
1) It is subtle breakage that creates a major and completely unnecessary PITA for anyone who needs to write UIManager code that works across Pharo, Squeak, Croquet etc.
2) It weakens the framework. Toolbuilder is based on having the same semantics across platforms and UIs and this change means that the entire family of input requests is no longer reliable as it will behave differently between Pharo and anything else in existence.
3) The alternatives are every bit as good. The protocol complication of using onCancel: are minimal to non-existent (since in many cases the ability to provide a cancel action is what you'll want anyway) and even if that were the case, a new protocol that over time can be supported by other UIs would solve that completely and in a proper evolutionary way.
4) With the choice you've made, you need to touch every user of that method anyway. If that's true, there is no penalty for changing the protocol and it will make migration easier since you can simply browse for all senders of #request: and find those that haven't been converted yet.
Please do consider these issues carefully. I really don't think there is any advantage for you or your users by introducing such a subtle breakage.
-- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings