Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Normative: Make PrivateName a defensible class
This patch makes PrivateName a deeply frozen, "defensible" class, whereas in previous iterations, it was represented as a primitive, an ordinary class, and finally an object with own methods and a null prototype. The goal of using a defensible class by default, as opposed to being an ordinary class that users can freeze, is to protect privacy by deafult against complex scenarios. In modern JavaScript code, a decorator which others depend on may be implemented in a deep dependency and unable to capture/freeze the original value of PrivateName.prototype proerties. As a result, monkey-patching of that object can make it difficult to preserve privacy of decorated private class elements. A defensible-by-default PrivateName achieves the goal. See [1] for past discussion. The details of the PrivateName class are as follows, based on advice [2] from Mark Miller: - The constructor, prototype, and all methods are frozen objects. - Instances are frozen. - The constructor and prototype have null [[Prototype]] values. - The constructor, when called, throws a TypeError, matching the decision [3] to not expose the PrivateName constructor. If we were to support new-ing the PrivateName constructor, the semantics would be such that instance is frozen only if new.target === PrivateName. [1] #68 [2] #129 (comment) [3] #68 (comment)
- Loading branch information
Showing
1 changed file
with
94 additions
and
14 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters