[ANSI-Smalltalk] #contents on WriteStream
Richard O'Keefe
ok at cs.otago.ac.nz
Fri Oct 17 05:52:02 BST 2008
What I don't understand is why WriteStream and ReadWriteStream
should do _different_ things with #contents.
In Squeak and VisualWorks,
(WriteStream on: String new)
nextPutAll: 'abc';
skip: -1;
contents
==> 'ab'
but
(ReadWriteStream on: String new)
nextPutAll: 'abc';
skip: -1;
contents
==> 'abc'.
This makes no sense whatever to me. This looks to me like
a historic bug which has been accidentally preserved.
*MOVING* in a collection stream and
*REMOVING* elements from the collection
are different things. #skip: is a move, not a remove.
As it happens, I had been wondering about mentioning an
operation on file output streams that would be useful;
#truncate.
?.?.?.? Message: truncate
Synopsis
Truncates the contents of a stream at its
current position.
Definition: <sequencedStream>
Removes all the receiver's future sequence
values.
Return Value
UNSPECIFIED
Errors
The backing store of the stream cannot be
truncated.
For collection-based streams, the implementation is trivial:
set the high water mark (readLimit) to the current position.
For file-based streams, it takes OS-dependent code. Some
systems will be able to use ftruncate(2), some will use
other means, some may be unable to do it at all. Windows,
Mac OS, and anything with a POSIX interface should be able
to at least try.
Anyone who *wants* to remove things from the end of a
WriteStream should be allowed to do
(WriteStream on: String new)
nextPutAll: 'abc';
skip: -1;
truncate "THIS IS THE NEW BIT";
contents
and that should work exactly the same way for ReadWriteStreams.
More information about the ANSI-Smalltalk
mailing list