[Pharo-project] readFrom: vs readFromString:
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 ? Nicolas
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 ? 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. 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 ? Sven
2011/10/30 Sven Van Caekenberghe <sven@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
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@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
There is certainly room for both approaches, and reading from a stream is the more logical time to stop at the end of valid input. There are times when I know the stream should be at its end, and I test for that in those cases. Dolphin contains some *ToText classes that do some very useful things (supporting both direction via #leftToRight: and #rightToLeft:), especially DateToText and TimeToText, which have a #format aspect. It's not really the same problem, but worth keeping in mind as we tackle this. The short version, +1. Bill ________________________________________ 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: Sunday, October 30, 2011 12:07 PM To: The general-purpose Squeak developers list; Pharo Development Subject: [Pharo-project] readFrom: vs readFromString: 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 ? Nicolas
On Sun, Oct 30, 2011 at 05:07:48PM +0100, 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 ?
This sounds right to me. I suspect that it might be difficult to do this without breaking some external packages, but it does seem like the right thing to do. Dave
participants (5)
-
David T. Lewis -
Nicolas Cellier -
Schwab,Wilhelm K -
Stéphane Ducasse -
Sven Van Caekenberghe