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