Suggested stream-protocol condition behaviour.

[Brian Rice]

These are some good improvements.

In answer to the query in there,

hunk ./doc/progman.lyx 9944
+ If the stream fills up (signalling Exhausted) during the write, the  
signal
+ is propagated to the caller of nextPutAll:.
+\begin_inset Marginal
+collapsed false
+
+\layout Standard
+
+how can we let the caller know how far through the write the  
condition was
+ signalled?
+\end_inset

The answer is probably to make a PartialWrite derived from  
SeriousCondition and Stream Condition, which has a slot for the  
number of elements successfully written.

The other question, re isAtEnd:

hunk ./doc/progman.lyx 9996
- answers whether or not the stream has reached some limit.
+ answers whether or not the stream has reached some input limit:  
returns
+ true if-and-only-if next or peek would signal Exhausted; returns false
+ otherwise (modulo signalled Conditions).
+ Returns false if more elements may be available for reading.
+
+\begin_inset Marginal
+collapsed false
+
+\layout Standard
+
+Is this ambiguous? What if false is returned, next is called, and  
Exhausted
+ is raised? Do people really have to check all this stuff redundantly?
+\end_inset

You mean for network streams where the condition can change between  
one read and the next? Of course that would be a waste. I am unsure  
of a solution, however. The big problem is consistency in checking in  
terms of: should everything use a condition-handler or should  
everything check isAtEnd? Because with composing streams into  
pipelines, error propagation will travel along that pipeline...  
unless we make an explicit object for composing streams that  
"contains" such things, and I am not sure that that is a good idea  
anyway.

On Nov 4, 2005, at 2:46 PM, Tony Garnock-Jones wrote:

> Attached.
> <condition-suggestions.gz>

--
-Brian