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 <guillermopolito@gmail.com
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 < stephane.ducasse@inria.fr> 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 <nicolas.cellier.aka.nice@gmail.com> 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 <johan@inceptive.be>:
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 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
_______________________________________________ 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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project