[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