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