Limited compatibility with FileStream

[LinqLover]

We noticed several compatibility issues that severely limit the applicability of FS in Squeak:

• Different behavior of next: In Squeak's Files package, it answers nil when at the end of the stream. FS raises an error.

  e.g., this makes it incompatible with Json:

  FileSystem memory in: [:fs |
  fs / 'test.txt'
      writeStreamDo: [:s |
          'squeak' jsonWriteOn: s];
      readStreamDo: [:s |
          Json readFrom: s]] "⚡ Error: subscript is out of bounds: 8"

• No single-byte file stream option: In the Files package, StandardFileStream reads files byte per byte as opposed to MultiByteFileStream which uses a converter. All FSStreams 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 using StandardFileStream.

• basicBack is missing on FSReadStream which is sent from UTF8TextConverter in response to #skip:. E.g.:

  FileSystem memory in: [:fs |
  fs / 'test.txt'
      writeStreamDo: [:s |
          'squeak' jsonWriteOn: s.
          s nextPut: Character null];
      readStreamDo: [:s |
          Json readFrom: s]] "⚡ MNU: #basicBack"

  Does this implementation make sense?

  FSReadStream>>basicBack
  | result |
  result := handle at: position - 1.
  position := position - 1.
  isBinary ifFalse: [result := result asCharacter].
  ^ result

• 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 ... :-)

[j4yk]

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".

[LinqLover]

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

• [ ] todo

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!