nicolas cellier wrote:
> Am I all wrong?
> What do you think?

I think you're crazy ;-) A change like this is going to cause a huge 
amount of pain and will have fallout for *years* to come. That's because 
you're dramatically changing the rules of the game: Where previously 
#next at the end of stream would immediately return it will now start 
searching the stack, evaluating handler blocks, and *eventually* return. 
  You're switching from one bytecode to literally hundreds of messages 
with exception handling in the middle in this very common case. This 
will dramatically impact all areas of the system that use streams with 
completely unknown behavior if, for example, an application has an 
exception handler around that bit of stream code (every realistic 
application has; often more than a single one). So code that needs to 
run fast will have to be explicitly rewritten from the "next == nil" 
test to use "atEnd" instead to avoid that stack-searching, 
handler-evaluating overhead.

 From my perspective, this is a no-go area. If you really need streams 
to signal EndOfStream then the right way to do this is to write a new 
stream framework (or use one that supports it; perhaps Nile or Flow do) 
and gradually migrate code to that framework (in which case it can be 
tested and fixed as necessary). Everything else is basically suicide.

Cheers,
  - Andreas