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-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier
[nicolas.cellier.aka.n...@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.duca...@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 <jo...@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
