Hi Sven, On Thu, Apr 12, 2018 at 09:23:21AM +0200, Sven Van Caekenberghe wrote:
On 12 Apr 2018, at 08:33, Alistair Grant <akgrant0710@gmail.com> wrote:
...
In your example you've carefully exited by some other means than signalling end-of-file (Ctrl-D).
I don't think we can reasonably say "if you write code with Zinc streams, ensure that none of your users ever press Ctrl-D, they must always type 'quit' (or whatever)".
I left that open as an exercise for the reader - I knew you would try that ;-)
Glad that I didn't disappoint. :-)
The code was originally written for network streams and there it catches ConnectionClosed which is the network stream equivalent of EOF (more or less).
I think we need something like an EndOfStream exception which should be thrown in that case, instead of returning nil.
Returning nil from ZnCharacterReadStream or ZnCharacterEncoder when the stream is EOF is wrong IMHO. The stream being EOF is an exceptional situation (even though it is relatively common) and there is always #atEnd that works well in 99% of the cases.
AFAIK that is also the design decision taking by Xtreams (where I believe the Incomplete exception replaces #atEnd).
OK, this brings us full-circle. Earlier in the thread we wrote: On Tue, Apr 10, 2018 at 11:54:39PM +0200, Sven Van Caekenberghe wrote:
Alistair,
I am replying in-between, please don't take my remarks as being negative, I just like to straighten things out as clear as possible.
On 10 Apr 2018, at 22:14, Alistair Grant <akgrant0710@gmail.com> wrote:
At this point I think there are three options:
1. Modify Zinc to check the return value of #next instead of using #atEnd.
This is what all existing character / byte oriented streams in Squeak and Pharo do. At that point the Zinc streams can be used on all file / stdio input and output.
I agree that such code exists in many places, but there is lots of stream reading that does not check for nils.
2. Modify all streams to signal EOF in some other way, i.e. a sentinel or notification / exception.
This is what we were discussing below. But it is a decent chunk of work with significant impact on the existing code base.
Agreed. This would be a future extension.
I agree that raising an exception is a nicer solution (although for anyone who disagrees I'll also admit that there is a subjective element to that assessment). But the existing behaviour of returning nil on EOF has been around for a long time and works reasonably well, and as we agreed here, changing that behaviour will have a significant impact on the existing code base. None of this excludes Zinc streams adopting exceptions at any time in the future. So I'm going to respectfully disagree and say that I think to raise a MNU instead of returning nil is wrong, and that changing the Zinc streams isn't such a big deal. Cheers, Alistair