Removed promise antipattern from code example

[bergus]

See What is the explicit promise construction antipattern and how do I avoid it? on StackOverflow.
Promise evangelists say it should be burned with fire, and not appear in any possibly educational code examples :-)

[annevk]

Thank you @bergus, this indeed seems like something we should get right. @domenic, could you review this please?

[jakearchibald]

This looks correct to me. Dunno if there's a style that should be followed regarding semicolons, but the use of promises seems correct.

[annevk]

@bergus, could you add yourself to the acknowledgments section?

[domenic]

This was discussed a bit during the merge. There is a slight problem here, which is that the form @bergus advocates will cause memory to be consumed for the entire chain of promises (i.e. the first chunk's promise cannot be GCed until the last chunk's promise is GCed, which does not happen until the stream is closed/errored). This is a design flaw/bug of promises, discussed a lot previously in tc39/proposal-cancelable-promises#1 and linked places.

I am on the fence on this, but maybe it is better to advocate the "leaky" pattern in the hopes that we will one day fix it/optimize it in implementations?

[jakearchibald]

What leaks here? Just the promise object, or the chunks too?

[domenic]

Just promise objects. The individual promises fulfilled with each chunk are not retained. Instead it's just a long chain of pending promises resolved to the next item in the chain, until the last promise is finally fulfilled.

[jakearchibald]

I think that's probably ok in this case. Hopefully implementations can squash that chain?

[bergus]

Ah yeah the recursive promise chain memory problem.
Imo, this flaw should be fixed in the spec and in implementations.
@domenic I'm all for advocating the proper pattern. Its use should be encouraged, and if that puts pressure on implementations to fix the leak then mission accomplished :-) The antipattern with .then(resolve, reject) also prevents propagation of cancellation and similar things.
@jakearchibald I found the semicolon style weird as well, but just didn't want to change anything here.
@annevk Is my full real name required there?

[domenic]

Yeah, it's unfortunate that it's not a trivial fix (since the easy fix breaks the ability for subclasses to customize .then behavior).

[annevk]

@bergus no, it's completely up to you and only if you want to be listed. No requirements.

[annevk]

@bergus ping.

[annevk]

Thank you, landed as af4664d. Assumed you did not want to be listed at all.

[bergus]

Thanks, it's fine. If I'll change my mind and want to be acknowledged, I'll find something else to contribute :-)