And now, because of fixing Integer>>readFrom:, 'foo' asTime throws an exception and we all are a bit happier :D. On Wed, Aug 25, 2010 at 7:55 PM, Schwab,Wilhelm K <bschwab@anest.ufl.edu>wrote:
I would like to be *able* to use a read method to pull from a stream with other data in it. Whether it needs to be at the end when that is over is open for debate, perhaps left to the caller?? It is an important question. Off the top of my head, it seems that Dolphin somewhat dodges it for dates and times by taking strings. I can check on whether they raise errors if there is "stuff left over."
Again, I am fully supportive of raising errors by default. They help to fix a lot more trouble than they cause.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice@gmail.com] Sent: Wednesday, August 25, 2010 4:50 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 'foo' asTime
2010/8/25 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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.
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
Nicolas
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