cool now let us see where it breaks and fix.

Stef
On Aug 25, 2010, at 3:58 PM, Guillermo Polito wrote:

> I fixed Integer>>readFrom: yesterday.  Its in the inbox 
> http://code.google.com/p/pharo/issues/detail?id=2857&q=String%20Number&colspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty
> 
> On Wed, Aug 25, 2010 at 4:32 AM, Stéphane Ducasse <[email protected]> 
> wrote:
> Hi nicolas
> 
> If I understand you correctly we are in sync.
> Yes readFrom: should read or fails raising an Error
> and we should use Integer readFrom: 'foo' ifFail: [the default value that the 
> client knows that he wants]
> 
> Now we integrated your number parsers so this is strange that the behavior is 
> not like you mention
> did you make them backwards compatible?
> 
> So I would give a try to get readFrom: clean.
> Johan please give a try
> 
> Stef
> 
> 
> 
> > 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

Reply via email to