Open LinqLover opened 9 months ago
No standard specifies that next
should return nil rather than raising an error at the end of the stream. In fact the Blue Book says this:
The reading and writing messages each determine if a next element can be read or written and, if not, an error is reported.
(pp. 196, 197, July 1985 edition)
But since "reporting an error" is a bit vague: 1. you can change the method here to return nil, 2. no code that wishes to be portable should actually rely on this behavior...
If you want to read single bytes, why not use a binary stream? If you want characters, you must think about the encoding. When in doubt, use CP1252TextConverter or ISO88591TextConverter/Latin1TextConverter.
Looking at MultiByteFileStream>>basicNext, I suppose basicBack should make sure that the position does not go below zero.
I have already given @MariusDoe my blessing to let the FS streams inherit from Stream, copy further methods from there, or whatever makes sense to address the Stream behavior that is "missing".
No standard specifies that
next
should return nil rather than raising an error at the end of the stream. In fact the Blue Book says this:The reading and writing messages each determine if a next element can be read or written and, if not, an error is reported.
(pp. 196, 197, July 1985 edition)
But since "reporting an error" is a bit vague: 1. you can change the method here to return nil, 2. no code that wishes to be portable should actually rely on this behavior...
Oh, fair point. Though even an exact source code search for next ifNil:
and then filtering results by *stream*
yields 14 results ... Including TReadableStream>>#readInto:startingAt:count:
:o
If you want to read single bytes, why not use a binary stream? If you want characters, you must think about the encoding. When in doubt, use CP1252TextConverter or ISO88591TextConverter/Latin1TextConverter.
Thank you! I'm actually doing both after each other: First a byte, then a string, then a number, then a character ... In default Squeak, I just can send binary
and ascii
many times after each other to an existing stream.
Looking at MultiByteFileStream>>basicNext, I suppose basicBack should make sure that the position does not go below zero.
+1
I have already given @MariusDoe my blessing to let the FS streams inherit from Stream, copy further methods from there, or whatever makes sense to address the Stream behavior that is "missing".
Ok, thanks for the update!
We noticed several compatibility issues that severely limit the applicability of FS in Squeak:
Different behavior of
next
: In Squeak's Files package, it answersnil
when at the end of the stream. FS raises an error.e.g., this makes it incompatible with Json:
No single-byte file stream option: In the Files package,
StandardFileStream
reads files byte per byte as opposed toMultiByteFileStream
which uses a converter. AllFSStream
s require the use of a converter. Since there seems not to be something as a null converter (?), this makes it impossible to read files that were written usingStandardFileStream
.basicBack
is missing onFSReadStream
which is sent fromUTF8TextConverter
in response to#skip:
. E.g.:Does this implementation make sense?
No support for data get/put protocol which limits usage for Sounds and others. See https://github.com/hpi-swa/Squot/commit/4b35071bcf71240b0088910b39f48ad1beba9689 for more details. /cc @MariusDoe
In general, the question remains how much compatibility is desired ... but I would like it ... :-)