Richard A. O'Keefe  wrote:

>  It looks very much as if WriteStream>>on:
aCollection
>  should read
>  self on: aCollection from: 1 to: aCollection size.

I'm no expert but how is that change going to affect
existing methods which send messages to
WriteStream>>on: aCollection? 	

Before I show examples this is Squeak 3.5's
definition, of the method you cite, for reference:

WriteStream class>>	on: aCollection from: firstIndex
to: lastIndex
| len |
	collection _ aCollection.
	readLimit _ 
		writeLimit _ lastIndex > (len _ collection size)
						ifTrue: [len]
						ifFalse: [lastIndex].
	position _ firstIndex <= 1
				ifTrue: [0]
				ifFalse: [firstIndex - 1]
				

I did a quick scan of some senders of WriteStream on:
aCollection. For instance...

AddParameterRefactoring >>> newSelectorString
newSelectorString
	| stream keywords |
	stream := WriteStream on: String new.
	"... rest of expressions omited ..."
	
	...Won't making that change will result in the write
limit set to 0 for the stream temp variable
(WriteStream instance)? Won't newSelectorString's code
be upset when it tries to write to  stream?
	
	As well, with...	
	
	AbstractSound pitchTable>>pitchTable
	"AbstractSound pitchTable"

	| out note i |
	out =: WriteStream on: (String new: 1000).
	"... rest of expressions omited ..."
	
	...won't that change will cause the read limit to be
set to 1000? Didn't the authors wish to express
something by using the message send of on: to
WriteStream whose current implimentation sets the read
limit to 0?
	
Or am I missing something hear? 

Take care,

Anthony

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com