I submitted the fix (just removed the "failBlock:[^0]") and some new tests.
Name: SLICE-Issue-2857-StringToNumberConversionImprovement-GuillermoPolito.1 Author: GuillermoPolito Time: 24 August 2010, 7:17:42 pm UUID: 53653896-47e9-4451-920f-b8db7198bd06 Ancestors: Dependencies: Kernel-GuillermoPolito.735, KernelTests-GuillermoPolito.280 Number>>readFrom: and Integer>>readFrom: fails when they have to. Improved tests for reading Numbers from Strings On Tue, Aug 24, 2010 at 5:54 PM, Guillermo Polito <[email protected] > wrote: > Searching in the mails: > > <quote> > self assert: '123blabla' squeezeOutNumber equals: 123. > self assert: 'blabla123' squeezeOutNumber equals: 123. > self assert: 'blabla12blabla' squeezeOutNumber equals: 12. > self assert: ('12.3bla' squeezeOutNumber -12.3 ) abs < 0.0001. > self assert: '.1' squeezeOutNumber > 0. > </quote> > > I tried it in my image and > > 'bla' squeezeOutNumber. > > fails because of a primitive error... > > Anyway, the behavior is a little different from the existent in #readFrom: > Did you mean to let the dirty stuff to #squeezeOutNumber and throw the > error in the #readFrom:? > > > On Tue, Aug 24, 2010 at 5:49 PM, Stéphane Ducasse < > [email protected]> wrote: > >> >> >> http://code.google.com/p/pharo/issues/detail?id=2857 >> >> >> >> Which will be the impact in the system and other tools to throw an >> error >> >> when the conversion cannot take place? >> >> I think an error must be thrown, but should it be in Pharo 1.2 or in >> next >> >> version? >> >> >> > >> > My opinion: the system will be more predictible and cleaner ;) >> >> Me too. >> Still this is strange because I'm sure we did that with niko and introduce >> squeeze..... >> So may be we integrated some older code on top. >> I remember that even our changes broke scriptloader itself and the update >> stream :) >> >> > Nicolas >> > >> >> On Tue, Aug 24, 2010 at 11:45 AM, Nicolas Cellier >> >> <[email protected]> wrote: >> >>> >> >>> In squeak, (Integer readFromString: 'foo') ->Error >> >>> >> >>> Use: >> >>> - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, >> >>> - (Integer readFrom: 'foo' ifFail: []), to get nil >> >>> >> >>> Though it is possible, I dislike anwsering nil, because it would mean >> >>> a bunch of #readFrom: send should be protected by #ifNil: Blocks... >> >>> 1) That's nonsense, readFrom:ifFail: already does the work. >> >>> 2) you cripple the code with Error conditions and end up with >> >>> unreadable C-looking like code >> >>> (3 lines of Error condition crap for 1 line of underlying algorithm >> >>> at every function call) >> >>> 3) Exception handling can avoid long chains of ifFail: / ifNil: tests >> >>> >> >>> But that conversation already took place many times... >> >>> >> >>> I'd like the readFrom:ifFail: form to be generalized to other objects, >> >>> with default behaviour raising an Error. What do you think ? >> >>> >> >>> Nicolas >> >>> >> >>> 2010/8/24 Johan Brichau <[email protected]>: >> >>>> >> >>>> On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote: >> >>>> >> >>>>> I thought that readFromString: was raising an error and that >> >>>>> guessNumber* was returning zero >> >>>> >> >>>> I thought that too. I even have application code that shows that this >> >>>> used to return nil in some version of Pharo... >> >>>> But: >> >>>> >> >>>> 'foo' asInteger = nil >> >>>> Integer readFromString: 'foo' = 0 >> >>>> 'foo' asNumber -> Error >> >>>> >> >>>> aargh :-( >> >>>> >> >>>> disclaimer: currently testing this in pharo1.1 >> >>>> >> >>>> Johan >> >>>> _______________________________________________ >> >>>> 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 >> >> >> >> >> >> _______________________________________________ >> >> 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 >> >> >> _______________________________________________ >> 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
