On Aug 25, 2010, at 10:50 PM, Nicolas Cellier wrote: > 2010/8/25 Stéphane Ducasse <[email protected]>: >> 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 >> > > Yes, all the infrastructure is there, just change the top message to > be awkward-uncompatible ;) like Guillermo is suggesting.
I integrated the changes of guillermo. But readFrom:ifFail: is a nice API. > See also my other suggestion: implement #readFrom:ifFail: in every > class instead of #readFrom: and let readFrom default implementation to > just be > ^self readFrom: aStream ifFail: [self error: 'invalid format'] > > One question I'm not sure about is whether we should distinguish 2 API's: > - one for reading a single object and bark on extra-characters - IMO, > this would be the correct Behaviour of #readFromString: > - one for reading an object in a longer sequence of objects (just keep > the stream positionned after last character read) - this would be > readFrom: aStream Yes. I was thinking about something in the same vein so that we could walk on the stream Now I think that we should get a concrete case to learn from. First raising an error instead of zero is a good behavior and it may break some code. 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
