Repository navigation
Design Meeting Notes, 6/9/2017 #16415
Description
Activity
Just a comment with the ES5 down-emit with private members, if you considered the async/await down emit pattern by assuming
WeakMapit would be nice to have the down-emit and have those of us stuck in ES5 provide the polyfill.Reacted by Daniel RosenwasserAlso from a Dojo (@dojo) perspective we have debated a lot of putting private state in weak maps. We just know that if it is accessible, people will abuse it and the only way to to ensure it to promote it being truly private. The biggest challenge is that we have in some cases run into having to name privates in descendent classes silly things because of private member name conflicts, which makes code unclear.
And P.S. I hate the syntax for the record too... 😂
Reacted by Glen and AlexHey, thanks for the feedback about the syntax. The rationale is documented in the FAQ. Does anyone have any other suggestions?
The proposal breaks JScript 5.8 in IE 8.
What's the concern here?
Daniel Ehrenberg (@littledan) The FAQ doesn't address why the octothorpe (
#) sigil was chosen.I would think the js community would prefer the underscore (
_) which is a popular convention used to denote private member variables in current code as well as python and other languages.I would think the js community would prefer the underscore (_) which is a popular convention used to denote private member variables in current code as well as python and other languages.
The problem is that would break the internet, because the runtime engine must lookup the property differently. If every
_foosuddenly became truly private, imagine the horror. The sigil must be something that isn't currently a valid identifier in JavaScript to ensure that nothing breaks.Reacted by Steven and Jon RimmerSteven (@styfle) This is a great point. I added a new FAQ entry to explain the reasoning.
Reacted by StevenDaniel Ehrenberg (@littledan) Excellent, thank you for the detailed write up! I submitted a PR with some typo fixes.
I noticed the proposal-private-fields is Stage 1 but the proposal-class-fields is Stage 2 and seems to include private fields. Is this expected and if so, why?
Why WeakMaps not closures?
mihailik Because there's still just one method identity on the prototype, rather than the instance.
A rough prototype (play with it on CodePen)
function Apple() { // carrying private state function Private() {} Private.prototype = this; var private = new Private(); // bind methods to private state this.getColor = private.getColor.bind(private); this.setRed = private.setRed.bind(private); this.setGreen = private.setGreen.bind(private); } Apple.prototype.setRed = function() { this._color = 'red'; this.constructor.prototype.caption = 'Red Apple'; // mutating of public state, a bit convoluted }; Apple.prototype.setGreen = function() { this._color = 'green'; this.constructor.prototype.caption = 'Green Apple'; // mutating of public state }; Apple.prototype.getColor = function() { return this._color; }; var s = new Apple(); s.setRed(); console.log('setRed: ', s.getColor(), s.caption, s._color); s.setGreen(); console.log('setGreen: ', s.getColor(), s.caption, s._color); s.caption = 'Orange Apple?'; s._color = 'orange'; console.log('mutating directly: ', s.getColor(), s.caption, s._color);
Bound methods are being pursued separately, cc Ron Buckton (@rbuckton)
In some engines, using bound methods all the time is slower. Anyway, ES6
classdoes not have bound methods. Ordinary methods should be able to read private fields without suddenly switching into an entirely different mode, right?Having to re-bind methods for each instance is the cost of implementation using closures.
Is WeakMap implementation cheaper? Not obvious. Especially considering nontrivial performance/GC/JIT pressures of WeakMap.
Closure implementation has another win: it works on ES5 too.
Besides, the approach works when emitting ES6 classes too (again, CodePen to try):
class Apple { constructor() { // carrying private state function Private() {} Private.prototype = this; var _private = new Private(); // bind methods to private state this.getColor = _private.getColor.bind(_private); this.setRed = _private.setRed.bind(_private); this.setGreen = _private.setGreen.bind(_private); } setRed() { this._color = 'red'; this.constructor.prototype.caption = 'Red Apple'; // mutating of public state, a bit convoluted } setGreen() { this._color = 'green'; this.constructor.prototype.caption = 'Green Apple'; // mutating of public state } getColor() { return this._color; } } var s = new Apple(); s.setRed(); console.log('setRed: ', s.getColor(), s.caption, s._color); s.setGreen(); console.log('setGreen: ', s.getColor(), s.caption, s._color); s.caption = 'Orange Apple?'; s._color = 'orange'; console.log('mutating directly: ', s.getColor(), s.caption, s._color);
If you're talking about how TypeScript should implement this, then the desugaring you have there has observably different semantics than the spec. In particular, you can
.calla method which uses private state on a different receiver.If you're talking about what semantics to adopt to be efficiently implementable: WeakMaps in V8 aren't the fastest, but private fields will allow implementation with V8's internal-only "private symbols", which are more efficient. Not sure about other engines.
True! Desugaring is already observably different of course — so it's a matter of weighing pros and cons.
Besides, I think the whole approach may be worth considering in JS spec as well. Using
privatekeyword instead of '#' and making class methods accesses "tinted" so for anyX.Yaccess the runtime would check ifXis the same class andYis a field/method declared asprivate.It's more complex in the engine, but much benefit for the coders, and more sane mental model.
This isn't an engine issue, it's a language design issue. Please refer to the private fields FAQ to find documentation for the design.
I hope the TypeScript team tries to minimize observable differences, though I understand this isn't always possible. If differences are minimized, there will be a smaller "bump" for users who come from or to standard JS. In this case, which receiver is used is a pretty big difference.
Daniel Ehrenberg (@littledan) out curiosity, in which practical case you expect this be observed? In which cases do people define methods on a class, only to bind it to something else?
The JS FAQ is cautious on
privatekeyword due to complexity of VM implementation, not because language or mental model is hard. I don't think it's easy to find a JS user who would prefer the hash toprivate.Reacted by Yanick Rochon and Dmitry ZakharovThere is extensive discussion of this in the TC39 proposal. No good re-hashing it here, on an issue about the TypeScript implementation of the proposal. It would be best to focus the discussion in the proper forum, which considers the matter closed.
Reacted by Ryan Cavanaugh, mihailik, Daniel Ehrenberg and GlenAs usual I'd echo what Kitson Kelly (@kitsonk) just said
My closure-based suggestion is related to TypeScript. Any comments on that, regardless of JS implementation?
mihailik I'd encourage TypeScript to not use that kind of closure-based implementation, since it'd diverge from the possible native implementations in a pretty major way. TypeScript users may start depending on this behavior and be disappointed when they have to change their code later.
- locked and limited conversation to collaborators
on Jun 14, 2018
Stricter generic signature checks
any.a = babove, it simulates callingbwitha's parameters.masterand see what we can work with.Private Slots
Proposal: https://github.com/tc39/proposal-private-fields/ (Permalink)
Repo: https://tc39.github.io/proposal-private-fields/
How does this work with existing modifiers?
Can we offer a true downlevel translation?
Could give a mangled name in ES5/ES3.
What about using Symbols in ES6?
Weakmaps make it truly private.
P.S.
everyone hates the syntax.we're not big on the syntaxCompletely unrelated
We'll all need to go over the FAQ more closely on the private state proposal repo.