Normative: Use a non-frozen object to represent Private Names #88
Conversation
| @@ -67,7 +67,7 @@ function bound(elementDescriptor) { | |||
| // Whenever a read or write is done to a field, call the render() | |||
| // method afterwards. Implement this by replacing the field with | |||
| // a getter/setter pair. | |||
| function observed({kind, key, placement, descriptor, initializer}, get, set) { | |||
| function observed({kind, key, placement, descriptor, initializer}, PrivateName) { | |||
| assert(kind == "field"); | |||
| assert(placement == "own"); | |||
There was a problem hiding this comment.
The spec text says that this must be new PrivateName (on line 74)
spec.html
Outdated
| <p>The following steps are taken:</p> | ||
| <emu-alg> | ||
| 1. Return PrivateNameDescriptiveString(? ThisPrivateName()). | ||
| 1. Let _pn_ be ? ThisPrivateName(). | ||
| 1. Let _desc_ be _sym_'s [[Description]] value. |
spec.html
Outdated
| 1. Return PrivateNameDescriptiveString(? ThisPrivateName()). | ||
| 1. Let _pn_ be ? ThisPrivateName(). | ||
| 1. Let _desc_ be _sym_'s [[Description]] value. | ||
| 1. If _desc_ is *undefined*, return _desc_ be the empty string. |
spec.html
Outdated
| <p>This property has the attributes { [[Writable]]: *false*, [[Enumerable]]: *false*, [[Configurable]]: *true* }.</p> | ||
| </emu-clause> | ||
|
|
||
| <emu-clause id="sec-private-name-this-private-name" aoid=ThisPrivateName> | ||
| <h1>ThisPrivateName()</h1> | ||
| <emu-alg> | ||
| 1. Let _p_ be the *this* value. | ||
| 1. Return ToPrivateName(_p_). | ||
| 1. Let _O_ be the *this* value. |
There was a problem hiding this comment.
Can abstract operations access the receiver in this manner? I feel like what I’ve typically seen is that API methods extract the receiver and pass it to abstract ops as an argument.
|
I'm concerned about the security hazard of a non-frozen prototype. A bad actor could patch |
|
OK, I'm going to merge this patch since it gets us closer to where we are agreed we want to go. Frozen vs not frozen is a smaller change that we can iterate on, compared to primitive vs object (which this patch does in a way that I don't think we'll go back on). |
This patch changes PrivateName from a primitive type to a non-frozen object. Rather than passing the `get` and `set` functions to decorators, the PrivateName constructor is instead passed, and is no longer present as a property of the global object. The change is hoped to reduce implementation complexity compared to the previous primitive type semantics, and describes a possibility which was discussed at the March 2018 TC39 meeting. Applications which need an unmodified version of PrivateName's methods are recommended to make a copy of them early on before anything modifies them, similarly to any other JS built-in. Addresses #68
littledan
force-pushed
the
private-name-object
branch
from
2a3a93d
to
3f03ccf
Compare
This patch changes PrivateName from a primitive type to a non-frozen
object. Rather than passing the
getandsetfunctions to decorators,the PrivateName constructor is instead passed, and is no longer present
as a property of the global object.
The change is hoped to reduce implementation complexity compared to the
previous primitive type semantics, and describes a possibility which
was discussed at the March 2018 TC39 meeting.
Applications which need an unmodified version of PrivateName's methods
are recommended to make a copy of them early on before anything modifies
them, similarly to any other JS built-in.
Addresses #68