Stream.Writable has no need to inherit from Stream #2961
Comments
This will surely break at least some modules. As always, partial (~⅓) direct usage: |
|
Agreed with @ChALkeR . It should still be possible to prevent the breakage by using |
|
@ronkorving, the same could be said for I suspect inheriting from the Moreover |
|
@ChALkeR out of interest, how do you generate that list? |
|
@ronkorving With |
|
Cool :) |
|
Writable inherits from Stream so that writable streams that Node generates and hands to userland will still It's worth mentioning that streams1 streams aren't gone, or slated for deprecation — even in the post-streams2 world it's totally valid to create a streams1 stream, especially if you need to implement a different buffering strategy than what streams2+ provides. |
|
To me, this was as much about elegance and cleanup (if not more) than about performance. I really doubt that in the grand scope of things you would be able to measure anything (as long as I/O is involved). |
|
It's been a fairly safe assumption that I didn't realise until I looked it up just now but and relies on also, @nodejs/streams needs to be in on this discussion, it's theirs to decide anyway |
|
I think the analogy to the appendix is good in the sense that it seems like a useless holdover from the past at first glance, but in fact is not. The ability to check if something is an instance of a stream might not be the best way if we were starting all over again from scratch, but it would cause a large amount of backwards compatibility to change and any improvement changing it would create would be minor compared with the issues it caused. |
|
Maintaining backwards compatibility is a visible benefit for those of us using node heavily in production systems. In general, it makes upgrading easier, and keeps the community from splitting unnecessarily. I don't think this breakage is the worst, but it WOULD be a cost, and one with little to no tangible benefit. (Code gets a little bit prettier, but not faster or more featureful.) -1 from me, but if I'm happy to admit I might be overlooking some aspect of the decision. |
|
It has semantic value and could become useful again in the future. I'd say leave it in, however, it would be interesting to see if the performance impact of this is measurable. |
|
@michaelnisi That's the $64,000 question (boy, I'm getting old): is there any reason to believe it will become useful again in the future? Its existence may be a result of code smell to begin with. However, this speculation is no reason to remove the Stream class. If there's even a remote chance of it becoming useful again in the future, that is a -1. |
ChALkeR
added
the
semver-major
|
Closing this. Don't see this ever happening, and the benefits are way too limited. |
Writablecurrently inherits fromStreamwithout any visible benefit. Stream only exposespipe()which Writable's own prototype replaces. Would it not be beneficial to make Writable inherit straight from EventEmitter? That way, all EE related API would not need to go one level deeper into the prototype chain, and its constructor would speed up a bit.I'm asking for feedback, because I'm not sure about drawbacks, or how Duplex may ruin this idea. The only thing that this will break is
myWritable instanceof Streamtests. That is BC breakage, but the effects should be very limited I imagine. Also, it doesn't seem to happen anywhere in Node itself.The text was updated successfully, but these errors were encountered: