stream: use more explicit statements#13863
Conversation
Can you show how you determined this? Also, what is "better" ? |
|
Ping @nodejs/streams |
|
@BridgeAR That leaves some questions though, like:
|
How can you be sure of this? If you want to get rid of the |
|
@TimothyGu I forgot about the object mode even though it does not really work with the object mode and the error thrown in that situation is actually wrong. I added a test for the object mode and changed to throw that error always when using @mscdex there is more to read about this in his blog post. As far as I know it's mainly about Turbofan and that being explicit is always best but I guess @bmeurer can answer these questions better than me. |
lib/_stream_wrap.js
Outdated
There was a problem hiding this comment.
The object mode check could actually be moved in the StreamWrap constructor but it is currently possible to change the objectMode variable from an existing stream and in that case the upper check would not be sufficient anymore.
It is explicitly noted in the docs that this is not safe but I'm thinking about opening a PR to make the objectMode read only.
@mcollina do you think that's reasonable?
There was a problem hiding this comment.
Streams implementors often change objectMode after the fact, so we cannot assume that. It'd a semver-major change, and several of us are -1 on those.
|
PTAL |
lib/_stream_wrap.js
Outdated
There was a problem hiding this comment.
Well, the error code was very specific and somewhat misleading that objectMode would or should not trigger this even though objectMode always would have resulted in a misleading error since it's first existence.
I think now it better represents both cases. I do see that it's not ideal to rename the code though.
There was a problem hiding this comment.
Given that I don't believe the other error code had actually shipped in a release yet, this is fine. Definitely makes this semver-major tho.
There was a problem hiding this comment.
The new error code needs to be included in the docs tho
|
The linter is failing, can you fix that? |
|
I'm flagging this as semver-major because it changes the error code. cc @jasnell |
lib/_stream_transform.js
Outdated
There was a problem hiding this comment.
This potentially could be a breaking change given that it would miss other falsy values potentially passed for cb
There was a problem hiding this comment.
I checked. We are setting this internally, it's not user-driven.
9e2a0de to
56f21ed
Compare
Using objectMode with stream_wrap has not worked properly before and would end in an error. Therefore prohibit the usage of objectMode alltogether. This also improves the handling performance due to the cheaper chunk check and by using explicit statements as they produce better code from the compiler.
56f21ed to
5ff0107
Compare
|
Comment addressed and rebased due to a conflict. @mcollina I could change the error in a separate commit to allow the main change without being semver-major if you like me to. But IMHO this is not semver-major as the error code has not yet landed in any release (to my best knowledge). |
|
CI before landing: https://ci.nodejs.org/job/node-test-pull-request/8874/ |
|
Failures are unrelated, landing. |
|
Landed as 1b54371. |
Using objectMode with stream_wrap has not worked properly before and would end in an error. Therefore prohibit the usage of objectMode alltogether. This also improves the handling performance due to the cheaper chunk check and by using explicit statements as they produce better code from the compiler. PR-URL: #13863 Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Writing explicit statements produces better outcomes from the
compiler.
More important though: the instanceof Buffer check is expensive
and can be avoided as nothing besides strings could be passed
to the handler. This also fixes a TODO entry.
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passesAffected core subsystem(s)
streams