> 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...
Sounds really what we want :)
after users can also do squeezeNumberOutOfString: stringOrStream onError: [0]
> Anyway, the behavior is a little different from the existent in #readFrom:
This is the key point
> Did you mean to let the dirty stuff to #squeezeOutNumber and throw the error
> in the #readFrom:?
Yes. Now we should identify user of readFrom: that in fact are expecting
squeezeOutNumber and fix them.
Stef
>
> 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
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
