Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[stream] Make _readableState and _writableState part of the public API #7629

Closed
mcollina opened this issue Jul 9, 2016 · 18 comments
Closed
Labels
feature request Issues that request new features to be added to Node.js. meta Issues and PRs related to the general management of the project. stream Issues and PRs related to the stream subsystem.

Comments

@mcollina
Copy link
Member

mcollina commented Jul 9, 2016

Following up from #7077 (comment), and other discussion.

One of the problem that has lead to breaking userland stream modules is related to the fact that they rely on functionality available in _readableState and _writableState that is not documented, and that is the only possible way for solving some issues, like knowing if a stream is in objectMode: true, clearing up the leftover write callbacks, and many other functionalities.

I propose we document, standardize and test a piece of _readableState  and _writableState.

I think we should have been able to spot mafintosh/duplexify#6 before releasing, sigh. @calvinmetcalf @thealphanerd are we setting readable-stream in passthrough mode for citgm run?

I am opening this discussion here rather than in readable-stream because I would like all possible feedback. As @mikeal said, "So, what are we gonna do about streams?" openjs-foundation/summit#16 (comment).

@nodejs/streams we might want probably put this at in our next meeting.

cc @ronkorving @mafintosh

@mcollina mcollina added stream Issues and PRs related to the stream subsystem. meta Issues and PRs related to the general management of the project. labels Jul 9, 2016
@mcollina mcollina changed the title Make _readableStream and _writableStream part of the public API [stream] Make _readableStream and _writableStream part of the public API Jul 9, 2016
@vsemozhetbyt
Copy link
Contributor

Are the '_readableStream' and '_writableStream' typos in the title?

@mcollina mcollina changed the title [stream] Make _readableStream and _writableStream part of the public API [stream] Make _readableState and _writableState part of the public API Jul 9, 2016
@mcollina
Copy link
Member Author

mcollina commented Jul 9, 2016

@vsemozhetbyt good catch!

@mscdex
Copy link
Contributor

mscdex commented Jul 9, 2016

Related: #6799

@mscdex
Copy link
Contributor

mscdex commented Jul 9, 2016

I personally think that having a single, non-underscore-prefixed property (to minimize impact) to house all state would be ideal (e.g. stream.streamState with stream.streamState._readable, etc. as necessary).

@mafintosh
Copy link
Member

Adding any properties by now will just make things more complicated in userland though as you'd have yet another thing to test for.

I'm 👍 on just making _readableState and _writableState part of the public readonly api - this is how they are used right now anyway.

@mscdex
Copy link
Contributor

mscdex commented Jul 9, 2016

Well technically it'd be trading two existing properties for one ;-)

I just don't like setting a precedent by documenting an underscore-prefixed property. It's already bad enough that _readableState is already publicly "documented" and its use is being encouraged....

@mcollina
Copy link
Member Author

mcollina commented Jul 9, 2016

@mscdex Technically a single property is not correct, as you can have a Transform that is in objectMode only on one side.

@vkurchatkin
Copy link
Contributor

_readableState and _writableState should remain private. If some functionality is missing, it should be added to stream instances instead

@mafintosh
Copy link
Member

adding the properties directly on the stream instances will likely break some modules as inheritance from streams is encouraged. it'll also make it complicated for module authors to determine if a property was set by the stream impl or the userland subclass as you dont know which version of streams an instance was created with

@vkurchatkin
Copy link
Contributor

adding the properties directly on the stream instances will likely break some module

We have 2 options:

  • find names that doesn't break any modules
  • use static functions instead

@mcollina
Copy link
Member Author

mcollina commented Jul 9, 2016

I'm not convinced on new properties, because it won't have an impact short-term. There are modules/applications that depends on these properties, because there aren't ways of solving certain issues using public APIs in a backward-compatible way.

@vkurchatkin
Copy link
Contributor

Documenting properties, prefixed with underscore essentially destroys convention and will eventually lead to a situation where we have to document all private properties.

So, a that very least, we need to remove underscores.

@mcollina
Copy link
Member Author

@vkurchatkin I agree. However the problem is that modules uses the _-prefixed properties in the wild. At this point in time, it's impossible for us to know what should we should semver about or not.
So, this solution helps in the long-term but not in the short-term.

I'm also a solution I could be happy with. My point is that we need to something to avoid this issue.

@Fishrock123 Fishrock123 added the feature request Issues that request new features to be added to Node.js. label Jul 11, 2016
@lance
Copy link
Member

lance commented Jul 11, 2016

Note this was also discussed here #6799

sam-github pushed a commit to sam-github/node that referenced this issue Dec 14, 2016
The MSI install scope was set to the WiX default, which is per-user.
However, with UAC, it could not be installed by a standard user because
InstallPrivileges is elevated by default, hence the install scope
should be set to per-machine. Furthermore, the default install path is
a per-machine location and setting the system path requires
administrator privileges.

By changing the InstallScope to perMachine, Start Menu shortcuts are
placed in ProgramData and not the installing user's AppData folder,
making the shortcuts available to other users. This also fixes the
installation when AppData is a network folder.

The custom action is necessary to allow upgrades. Since a per-machine
MSI cannot upgrade an application installed per-user, the custom action
checks if there is going to be an upgrade to a previous version
installed per-user and sets the installation as per-user to allow
upgrading. Hence, the advantages of installing per-machine will only
apply in fresh installations.

Fixes nodejs#5849
Fixes nodejs#7629

PR-URL: nodejs/node-v0.x-archive#25640
Reviewed-By: Alexis Campailla <alexis@janeasystems.com>
Reviewed-By: Bert Belder <bertbelder@gmail.com>
@Trott
Copy link
Member

Trott commented Jul 8, 2017

Although conversation appears stalled, this hasn't reached a conclusion one way or the other, has it?

@mcollina
Copy link
Member Author

mcollina commented Jul 8, 2017

There is no consensus on this one and all the relative issues. I can put to together a report for @nodejs/ctc, and we might want to pick a direction. I do not think we can reach consensus otherwise.

@caub
Copy link

caub commented Nov 8, 2017

I don't understand the few people who thumbed down

also maybe just simpler getters stream.readableState would return _readableState

@mcollina
Copy link
Member Author

This can be closed, we are pursuing #445 and adding accessors for the properties that needs access to _readableState  and _writableState. Sorry for the long wait, this could have been closed earlier.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Issues that request new features to be added to Node.js. meta Issues and PRs related to the general management of the project. stream Issues and PRs related to the stream subsystem.
Development

No branches or pull requests

9 participants