[Pharo-project] [squeak-dev] readFrom: vs readFromString:

Stéphane Ducasse stephane.ducasse at inria.fr
Mon Oct 31 20:44:57 UTC 2011


Nicolas 

We are interested in the rationalization of the code you propose.
Send it and we will integrate it.
May be this is because of Bach music but I like regularly in code :)

Stef

On Oct 30, 2011, at 8:42 PM, Nicolas Cellier wrote:

> 2011/10/30 Sven Van Caekenberghe <sven at beta9.be>:
>> Nicolas,
>> 
>> On 30 Oct 2011, at 17:07, Nicolas Cellier wrote:
>> 
>>> There is a huge mess in #readFrom: implementation.
>>> Some classes will signal trailing characters as a bug, some other
>>> won't and will simply leave the stream positioned after the valid
>>> part.
>>> I propose to change this behaviour uniformly:
>>> - readFrom: aStream will never fail on trailing chars (hey, it's a
>>> stream, it's up to sender to interpret the tail)
>>> - readFromString: aString will always forbid trailing char (it's not a
>>> stream, so this garbage is most probably an error and cannot be
>>> ignored silently)
>>> 
>>> What do you think ?
>> 
>> Will that not break the idiom (lazy implementation)
>> 
>> readFromString: string
>>        ^ self readFrom: string readStream
>> 
>> ?
> 
> That's it, I would change for something like
> 
> readFromString: aString
>    | aStream newInstance |
>    aStream := aString readString.
>    newInstance := self readFrom: aStream.
>    aStream atEnd ifFalse: [FormatError raise].
>   ^newInstance
> 
> 
>> 
>> BTW, what I miss in Smalltalk is a way to read from some position to another without all the terrible copying, either from a stream or from a string.
>> 
> 
> There is ReadStream class>>on:from:to: but I recommend testing and
> testing again, because Stream implementation is ... not crystal clear.
> 
>> Consider parsing something like this '2011-10-30T17:17:47+01:00', the fields are fixed and pretty simple, but I can't think of an efficient way to do it, can you ?
>> 
> 
> Don't know... Some pattern matching, maybe with a simple regexp.
> PEG might be simple too.
> Qualifying as "efficient" however raise the bar a bit high ;)
> 
> Nicolas
> 
>> Sven
>> 
>> 
>> 
> 




More information about the Squeak-dev mailing list