ncellier at ifrance.com
Wed Nov 7 00:53:47 UTC 2007
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
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.
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.
> - Andreas
More information about the Squeak-dev