October 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Fwd: Issue 1129 in pharo: UIManager #request: and #multilineRequest do not distinguish between empty and cancel

by Miguel Enrique CobÃ¡ Martinez

El jue, 01-10-2009 a las 21:27 +0200, Henrik Sperre Johansen escribiÃ³: > I'm saying that in my eyes, it seems like the best option because: > - It keeps the current behaviour of handling empty input and cancel the > same way. At least in my experience, this is the common case. > - It corrects the deficiency that there's currently no way to handle the > two differently (which in my eyes is the real bug). > - Using a default where you're likely to have to handle nil and empty in > the same way seem (to me at least) in some ways just as bad as > implementing do: on Object. > - The new method request:onCancel: will show up right below request:, so > it's easy to spot if you find yourself in the exceptional situation > where you DO need to handle these cases differently. (Especially with a > method comment explaining that's exactly what it's intended for) > - As an added benefit, it also keeps compatability with Squeak :) Very well spoke but I'm not convinced. If there are a correct method (request:onCancel:) the class comments will suggest to use it for everything, just passing an empty block to cancel if you don't want to do anything. Besides, the request method will exist and will be not removed. So in the image we have code that is not to be used and new code that is suggested to be used. With time (if the laziness isn't big) some packages will be converted to use the new suggested code. Some of them will never do. The problem is, we have the opportunity to fix it, one and for all, accepting the work that that means (but not very hard because isn't something like using continuations, threads or using the thisContext methods, so everyone could do it with just a couple minutes involved). Pharo has already walk a long way in improving and unloading not so good/unwanted code. The same will happen in next milestones when the FileDirectory code is removed. *That* is really a hard breakage. This is in comparison, just a simple find senders, rewrite method on first package load on Pharo. So, again, I vote for the complete fixing and not give a second thought on the Squeak compatibility. Of course, I will contribute coding time to help this task finish as soon as posible. Just MHO. > > Cheers, > Henry > > On 01.10.2009 19:07, StÃ©phane Ducasse wrote: > > Thanks henry > > Now we will to make a synthesis of all the options and pros and cons. > > I'm too tired to get a clear idea.n but what you are saying that this > > is better > > to keep resquest funky behavior and introduce request:onCancel: > > > > Stef > > > > > >>>> I see two options: > >>>> > >>>> - yours is to complicate the API in order to keep backward > >>>> compatibility with the code base and thus avoiding bugs. > >>>> - mine is to fix the problem once and for all. Yes, it also means > >>>> bugs > >>>> will appear during the period of fixing which can take some time > >>>> > >>> the point andreas is to deprecate request:* so that when you see > >>> where > >>> to change instead > >>> of getting bitten. > >>> > >>> Stef > >>> > >> Deprecation sounds like a bad solution in this case to me. > >> It's useful when functionality has either been > >> - Moved > >> - Removed > >> - Changed in a way that results in a silent failure > >> > >> In this case, either: > >> -It's changed in both Squeak and Pharo, and you get MNU's everywhere > >> for the old ifEmpty. None of the 3 cases above is satisfied, so I > >> don't really see the benefit of deprecation here. You still have to > >> change your app, replacing all calls to the now deprecated to the > >> new one, plus make sure the code at each spot handles the nil case. > >> - It's deprecated just one place, leading to extra porting overhead > >> if you have to change both the method name and the answer handling. > >> (plus the other dialect would have to add a deprecated ask: method > >> telling you how to conform to semantics). > >> > >> > >>> > >>>> Please let me comment on your reasons: > >>>> > >>>> On Tue, Sep 29, 2009 at 6:31 PM,<codesite-noreply(a)google.com> > >>>> wrote: > >>>> > >>>>> 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. > >>>>> > >>>> I do not agree. Squeak doesn't have to change its implementation of > >>>> #request:. Clients can just test for the nil value without wondering > >>>> if it is going to be returned (in Pharo) or not (in Squeak). > >>>> > >>>> This has an immediate consequence : you can apply the two changesets > >>>> which replace #isEmpty by #isEmptyOrNil after each call to > >>>> #request:. > >>>> You don't have to change #request: for this. > >>>> > >> That's false. > >> I suspect you only considered the case of porting Squeak code to > >> Pharo (which doesn't fail silently anyways, which is the major PITA, > >> you get an UndefinedObject>> MNU). > >> Porting code written in Pharo, f.ex. using ifNotNil: to handle an > >> action where empty input is allowed, WILL fail silently in Squeak if > >> request:* is not modified, resulting in a cancel action replacing > >> the previous value with an empty string. > >> > >> > >>>> > >>>> > >>>>> 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. > >>>>> > >>>> > >>>> To me, UIManager is broken. > >>>> > >> I agree, the issue is whether the default behaviour of handling > >> empty input and cancel the same way is what's broken, or the fact > >> that no way of handling such a case at all is provided. > >> > >> Considering the amount of times I've had to add ifEmpty: clauses > >> doing the same as ifNil: to request: call return values in VW (which > >> returns nil), I'd say the latter. > >> > >> > >>>> I agree that #onCancel: can be interesting on its own. However, I > >>>> see > >>>> it more as a new interesting feature whereas I'm talking about bug > >>>> fixing. > >>>> > >> Andreas has a good point, changing the current behaviour will either: > >> a) Lead to a lot of changes (albeit simple ones) for everyone if > >> adopted everywhere. > >> b) Lead to subtle errors when porting between dialects if adopted > >> just in one place. > >> > >> The fact it's been the way it is without getting changed so far, and > >> my anecdotal experiences in VW implies to me that the case where you > >> want to distinguish between an empty response and a cancel is the > >> exception rather than the rule. > >> Therefore, I support the option of adding explicit onCancel: aBlock > >> versions, and use those in the cases it's needed, rather than > >> changing the underlying behaviour, leading to either situation a) or > >> b) above. > >> > >> Cheers, > >> Henry > >> > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Oct. 1, 2009

Re: [Pharo-project] Fwd: Issue 1129 in pharo: UIManager #request: and #multilineRequest do not distinguish between empty and cancel

by Henrik Sperre Johansen

I'm saying that in my eyes, it seems like the best option because: - It keeps the current behaviour of handling empty input and cancel the same way. At least in my experience, this is the common case. - It corrects the deficiency that there's currently no way to handle the two differently (which in my eyes is the real bug). - Using a default where you're likely to have to handle nil and empty in the same way seem (to me at least) in some ways just as bad as implementing do: on Object. - The new method request:onCancel: will show up right below request:, so it's easy to spot if you find yourself in the exceptional situation where you DO need to handle these cases differently. (Especially with a method comment explaining that's exactly what it's intended for) - As an added benefit, it also keeps compatability with Squeak :) Cheers, Henry On 01.10.2009 19:07, StÃ©phane Ducasse wrote: > Thanks henry > Now we will to make a synthesis of all the options and pros and cons. > I'm too tired to get a clear idea.n but what you are saying that this > is better > to keep resquest funky behavior and introduce request:onCancel: > > Stef > > >>>> I see two options: >>>> >>>> - yours is to complicate the API in order to keep backward >>>> compatibility with the code base and thus avoiding bugs. >>>> - mine is to fix the problem once and for all. Yes, it also means >>>> bugs >>>> will appear during the period of fixing which can take some time >>>> >>> the point andreas is to deprecate request:* so that when you see >>> where >>> to change instead >>> of getting bitten. >>> >>> Stef >>> >> Deprecation sounds like a bad solution in this case to me. >> It's useful when functionality has either been >> - Moved >> - Removed >> - Changed in a way that results in a silent failure >> >> In this case, either: >> -It's changed in both Squeak and Pharo, and you get MNU's everywhere >> for the old ifEmpty. None of the 3 cases above is satisfied, so I >> don't really see the benefit of deprecation here. You still have to >> change your app, replacing all calls to the now deprecated to the >> new one, plus make sure the code at each spot handles the nil case. >> - It's deprecated just one place, leading to extra porting overhead >> if you have to change both the method name and the answer handling. >> (plus the other dialect would have to add a deprecated ask: method >> telling you how to conform to semantics). >> >> >>> >>>> Please let me comment on your reasons: >>>> >>>> On Tue, Sep 29, 2009 at 6:31 PM,<codesite-noreply(a)google.com> >>>> wrote: >>>> >>>>> 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. >>>>> >>>> I do not agree. Squeak doesn't have to change its implementation of >>>> #request:. Clients can just test for the nil value without wondering >>>> if it is going to be returned (in Pharo) or not (in Squeak). >>>> >>>> This has an immediate consequence : you can apply the two changesets >>>> which replace #isEmpty by #isEmptyOrNil after each call to >>>> #request:. >>>> You don't have to change #request: for this. >>>> >> That's false. >> I suspect you only considered the case of porting Squeak code to >> Pharo (which doesn't fail silently anyways, which is the major PITA, >> you get an UndefinedObject>> MNU). >> Porting code written in Pharo, f.ex. using ifNotNil: to handle an >> action where empty input is allowed, WILL fail silently in Squeak if >> request:* is not modified, resulting in a cancel action replacing >> the previous value with an empty string. >> >> >>>> >>>> >>>>> 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. >>>>> >>>> >>>> To me, UIManager is broken. >>>> >> I agree, the issue is whether the default behaviour of handling >> empty input and cancel the same way is what's broken, or the fact >> that no way of handling such a case at all is provided. >> >> Considering the amount of times I've had to add ifEmpty: clauses >> doing the same as ifNil: to request: call return values in VW (which >> returns nil), I'd say the latter. >> >> >>>> I agree that #onCancel: can be interesting on its own. However, I >>>> see >>>> it more as a new interesting feature whereas I'm talking about bug >>>> fixing. >>>> >> Andreas has a good point, changing the current behaviour will either: >> a) Lead to a lot of changes (albeit simple ones) for everyone if >> adopted everywhere. >> b) Lead to subtle errors when porting between dialects if adopted >> just in one place. >> >> The fact it's been the way it is without getting changed so far, and >> my anecdotal experiences in VW implies to me that the case where you >> want to distinguish between an empty response and a cancel is the >> exception rather than the rule. >> Therefore, I support the option of adding explicit onCancel: aBlock >> versions, and use those in the cases it's needed, rather than >> changing the underlying behaviour, leading to either situation a) or >> b) above. >> >> Cheers, >> Henry >> > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

Oct. 1, 2009

Re: [Pharo-project] Pharo ESUG Video

by StÃ©phane Ducasse

I will publish the slides of the presentation I will do saturday at Paris. Stef On Oct 1, 2009, at 9:06 PM, Andrey Larionov wrote: > It's better to publish text representation. The presentation is not > short enough for quickly observation. Also sound volume is not enough > to make this video attractive. IMO. > > On Thu, Oct 1, 2009 at 22:52, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Yes but things are said in a context at a certain moment, after we >> should move on and we >> are moving on. >> >> Stef >> >> On Oct 1, 2009, at 8:19 PM, Igor Stasenko wrote: >> >>> 2009/10/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> I'm not sure that this is wise to put this video on the webpage. >>>> >>> >>> why? Wouldn't you repeat the same words, what you have said in >>> public? :) >>> >>>> Stef >>>> >>>> On Sep 30, 2009, at 11:14 PM, Torsten Bergmann wrote: >>>> >>>>> http://mimer.msc.se/esug/M2U00055.mp4 >>>>> >>>>> includes Stef's presentation on Pharo from ESUG. >>>>> >>>>> Anyone able to link it on the webpage. >>>>> >>>>> Thx >>>>> T. >>>>> -- >>>>> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! >>>>> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 1, 2009

Re: [Pharo-project] Pharo ESUG Video

by Andrey Larionov

It's better to publish text representation. The presentation is not short enough for quickly observation. Also sound volume is not enough to make this video attractive. IMO. On Thu, Oct 1, 2009 at 22:52, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yes but things are said in a context at a certain moment, after we > should move on and we > are moving on. > > Stef > > On Oct 1, 2009, at 8:19 PM, Igor Stasenko wrote: > >> 2009/10/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> I'm not sure that this is wise to put this video on the webpage. >>> >> >> why? Wouldn't you repeat the same words, what you have said in >> public? :) >> >>> Stef >>> >>> On Sep 30, 2009, at 11:14 PM, Torsten Bergmann wrote: >>> >>>> http://mimer.msc.se/esug/M2U00055.mp4 >>>> >>>> includes Stef's presentation on Pharo from ESUG. >>>> >>>> Anyone able to link it on the webpage. >>>> >>>> Thx >>>> T. >>>> -- >>>> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! >>>> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 1, 2009

Re: [Pharo-project] better error handling

by StÃ©phane Ducasse

On Oct 1, 2009, at 8:02 PM, Mariano Martinez Peck wrote: > Hi folks: First of all I have to say I am pretty sad that error > handling hasn't a special place in the PBE. In my opinion having a > good error handling is a MUST in every piece of code. We need to use > exceptions. I didn't collaborate at all with PBE so I cannot say > anything to no one :) I will try to write something for the next > version if you want. But first... there is a chapter for the volume two. It is already written and was rewritten we will release it in the future for making the unpatient happy. > We need a better error handling. It is very common to have a > hierarchy of exceptions or errors. You have subclasses of Error for > example. And many times, you want to do or not to do or even do > something different depending on the error you got. Now, the > question is, how you do this in Squeak ??? have a look at the Exceptions test because they encode the rich exception mechanism of Smalltalk. I could send the exception chapter too :) > > This is the only (ugly) way I find to do it: > > [ a block of code where you do something that can singal different > exceptions ] > on: XXXErrror do: [ : ex | ex class = XXXError if True: [ 'I > do what I need to do when I get the error XXX' ]. > ex class = YYYError if > True: [ 'I do what I need to do when I get the error YYY' ]. > 'here I do in the rest of > the cases' > ] > > > But, I would like to have something like this: > > > [ a block of code where you do something that can singal different > exceptions ] > on: XXXError > do: [ : ex | 'I do what I need to do when I get the error > XXX' ] > on: YYYError > do: [ : ex | 'I do what I need to do when I get the error > YYY' ] > on: Error > do: [ : ex | 'here I do in the rest of the cases' ] > ensure: [ 'Here I do what I always need to do, no matter if > there is an error or not' ] > > > What do you think about this? does someone ever did something like > this ? perhaps we can put this as part of 1.1 > > I listen opinions. > > Best, > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 1, 2009

Re: [Pharo-project] Pharo ESUG Video

by StÃ©phane Ducasse

Yes but things are said in a context at a certain moment, after we should move on and we are moving on. Stef On Oct 1, 2009, at 8:19 PM, Igor Stasenko wrote: > 2009/10/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> I'm not sure that this is wise to put this video on the webpage. >> > > why? Wouldn't you repeat the same words, what you have said in > public? :) > >> Stef >> >> On Sep 30, 2009, at 11:14 PM, Torsten Bergmann wrote: >> >>> http://mimer.msc.se/esug/M2U00055.mp4 >>> >>> includes Stef's presentation on Pharo from ESUG. >>> >>> Anyone able to link it on the webpage. >>> >>> Thx >>> T. >>> -- >>> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! >>> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 1, 2009

Re: [Pharo-project] better error handling

by Hernan Wilkinson

do this... [[[[ a block of code where you do something that can singal different exceptions ] on: XXXError do: [ : ex | 'I do what I need to do when I get the error XXX' ]] on: YYYError do: [ : ex | 'I do what I need to do when I get the error YYY' ]] on: Error do: [ : ex | 'here I do in the rest of the cases' ]] ensure: [ 'Here I do what I always need to do, no matter if there is an error or not' ] 2009/10/1 Mariano Martinez Peck <marianopeck(a)gmail.com> > Hi folks: First of all I have to say I am pretty sad that error handling > hasn't a special place in the PBE. In my opinion having a good error > handling is a MUST in every piece of code. We need to use exceptions. I > didn't collaborate at all with PBE so I cannot say anything to no one :) I > will try to write something for the next version if you want. But first... > > We need a better error handling. It is very common to have a hierarchy of > exceptions or errors. You have subclasses of Error for example. And many > times, you want to do or not to do or even do something different depending > on the error you got. Now, the question is, how you do this in Squeak ??? > > This is the only (ugly) way I find to do it: > > [ a block of code where you do something that can singal different > exceptions ] > on: XXXErrror do: [ : ex | ex class = XXXError if True: [ 'I do what > I need to do when I get the error XXX' ]. > ex class = YYYError if True: [ 'I > do what I need to do when I get the error YYY' ]. > 'here I do in the rest of the > cases' > ] > > > But, I would like to have something like this: > > > [ a block of code where you do something that can singal different > exceptions ] > on: XXXError > do: [ : ex | 'I do what I need to do when I get the error XXX' ] > on: YYYError > do: [ : ex | 'I do what I need to do when I get the error YYY' ] > on: Error > do: [ : ex | 'here I do in the rest of the cases' ] > ensure: [ 'Here I do what I always need to do, no matter if there is an > error or not' ] > > > What do you think about this? does someone ever did something like this ? > perhaps we can put this as part of 1.1 > > I listen opinions. > > Best, > > Mariano > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 1, 2009

Re: [Pharo-project] Pharo ESUG Video

by Igor Stasenko

2009/10/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I'm not sure that this is wise to put this video on the webpage. > why? Wouldn't you repeat the same words, what you have said in public? :) > Stef > > On Sep 30, 2009, at 11:14 PM, Torsten Bergmann wrote: > >> http://mimer.msc.se/esug/M2U00055.mp4 >> >> includes Stef's presentation on Pharo from ESUG. >> >> Anyone able to link it on the webpage. >> >> Thx >> T. >> -- >> GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! >> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 1, 2009

[Pharo-project] better error handling

by Mariano Martinez Peck

Hi folks: First of all I have to say I am pretty sad that error handling hasn't a special place in the PBE. In my opinion having a good error handling is a MUST in every piece of code. We need to use exceptions. I didn't collaborate at all with PBE so I cannot say anything to no one :) I will try to write something for the next version if you want. But first... We need a better error handling. It is very common to have a hierarchy of exceptions or errors. You have subclasses of Error for example. And many times, you want to do or not to do or even do something different depending on the error you got. Now, the question is, how you do this in Squeak ??? This is the only (ugly) way I find to do it: [ a block of code where you do something that can singal different exceptions ] on: XXXErrror do: [ : ex | ex class = XXXError if True: [ 'I do what I need to do when I get the error XXX' ]. ex class = YYYError if True: [ 'I do what I need to do when I get the error YYY' ]. 'here I do in the rest of the cases' ] But, I would like to have something like this: [ a block of code where you do something that can singal different exceptions ] on: XXXError do: [ : ex | 'I do what I need to do when I get the error XXX' ] on: YYYError do: [ : ex | 'I do what I need to do when I get the error YYY' ] on: Error do: [ : ex | 'here I do in the rest of the cases' ] ensure: [ 'Here I do what I always need to do, no matter if there is an error or not' ] What do you think about this? does someone ever did something like this ? perhaps we can put this as part of 1.1 I listen opinions. Best, Mariano

Oct. 1, 2009

Re: [Pharo-project] Fwd: Issue 1129 in pharo: UIManager #request: and #multilineRequest do not distinguish between empty and cancel

by StÃ©phane Ducasse

Thanks henry Now we will to make a synthesis of all the options and pros and cons. I'm too tired to get a clear idea.n but what you are saying that this is better to keep resquest funky behavior and introduce request:onCancel: Stef >>> I see two options: >>> >>> - yours is to complicate the API in order to keep backward >>> compatibility with the code base and thus avoiding bugs. >>> - mine is to fix the problem once and for all. Yes, it also means >>> bugs >>> will appear during the period of fixing which can take some time >> >> the point andreas is to deprecate request:* so that when you see >> where >> to change instead >> of getting bitten. >> >> Stef > > Deprecation sounds like a bad solution in this case to me. > It's useful when functionality has either been > - Moved > - Removed > - Changed in a way that results in a silent failure > > In this case, either: > -It's changed in both Squeak and Pharo, and you get MNU's everywhere > for the old ifEmpty. None of the 3 cases above is satisfied, so I > don't really see the benefit of deprecation here. You still have to > change your app, replacing all calls to the now deprecated to the > new one, plus make sure the code at each spot handles the nil case. > - It's deprecated just one place, leading to extra porting overhead > if you have to change both the method name and the answer handling. > (plus the other dialect would have to add a deprecated ask: method > telling you how to conform to semantics). > >> >>> >>> Please let me comment on your reasons: >>> >>> On Tue, Sep 29, 2009 at 6:31 PM, <codesite-noreply(a)google.com> >>> wrote: >>>> 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. >>> >>> I do not agree. Squeak doesn't have to change its implementation of >>> #request:. Clients can just test for the nil value without wondering >>> if it is going to be returned (in Pharo) or not (in Squeak). >>> >>> This has an immediate consequence : you can apply the two changesets >>> which replace #isEmpty by #isEmptyOrNil after each call to >>> #request:. >>> You don't have to change #request: for this. > > That's false. > I suspect you only considered the case of porting Squeak code to > Pharo (which doesn't fail silently anyways, which is the major PITA, > you get an UndefinedObject >> MNU). > Porting code written in Pharo, f.ex. using ifNotNil: to handle an > action where empty input is allowed, WILL fail silently in Squeak if > request:* is not modified, resulting in a cancel action replacing > the previous value with an empty string. > >>> >>> >>>> 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. >>> >>> >>> To me, UIManager is broken. > > I agree, the issue is whether the default behaviour of handling > empty input and cancel the same way is what's broken, or the fact > that no way of handling such a case at all is provided. > > Considering the amount of times I've had to add ifEmpty: clauses > doing the same as ifNil: to request: call return values in VW (which > returns nil), I'd say the latter. > >>> >>> I agree that #onCancel: can be interesting on its own. However, I >>> see >>> it more as a new interesting feature whereas I'm talking about bug >>> fixing. > > Andreas has a good point, changing the current behaviour will either: > a) Lead to a lot of changes (albeit simple ones) for everyone if > adopted everywhere. > b) Lead to subtle errors when porting between dialects if adopted > just in one place. > > The fact it's been the way it is without getting changed so far, and > my anecdotal experiences in VW implies to me that the case where you > want to distinguish between an empty response and a cancel is the > exception rather than the rule. > Therefore, I support the option of adding explicit onCancel: aBlock > versions, and use those in the cases it's needed, rather than > changing the underlying behaviour, leading to either situation a) or > b) above. > > Cheers, > Henry

Oct. 1, 2009