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