Wrong.
VW does support it, and concerning efficiency, they are not that crazy.

True, there is a stack scan, but ONLY ONCE at the end of the stream.
If the stream is long enough, it will save A LOT of atEnd tests.
This is called optimistic programming.
Imagine that I ask you at each step "Are we arrived?"; you would not 
bear a very long walk, would you? That's what the atEnd test is doing.

In following mail and at http://bugs.squeak.org/view.php?id=6755 I 
already noticed possible exception handling problem that caused Marcus 
to retract this change. This is because EndOfStream were declared an 
Error instead of a Notification.

And testing next == nil is a ugly hack i reject because i have some 
collections with some nil.

I want for example to use
	aCollection lazily
		collect: [:e | e color];
		select: [:e | e notNil]
using LazyStreams iterating only once.
Absence of EndOfStream notification is just spoiling the game.
But nevermind, I will just publish on VW public store where I will find 
crazy guys interested.

Nicolas

Andreas Raab a écrit :
> 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
> 
>