Normative: Remove class decorator access to private names #151
Conversation
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
This patch makes it so that class decorators do not see private class elements. With this patch, only element decorators have the ability to do metaprogramming on private class elements. For field/method decorators, granting access to the private name seems syntactically clear and implied by the construct. There are also several critical use cases, including: - Limited-capability accessors (@reader) - Observation pattern (@Tracked) - Friends/testable (@testable) For access from class decorators to private, different people have had different intuitions: Some expect access, while others say it violates privacy. A workaround here, under this patch, is to use an element decorator for each private element, rather than a class decorator, to accomplish the same thing. This may be ugly, but it works for all the use cases I'm aware of. As a possible follow-on proposal, a specifically "trusted" type of decorator could be created, though the details are unclear. See #133
|
@erights Is this what you were picturing for the limitations on the use of private names? |
|
From your description in your comment above, yes, thanks!! Regarding the actual PR, I do not have, or do not remember, enough understanding of the surrounding context to check that it corresponds to your description. For lack of time, I must leave that to you and other reviewers. |
|
OK, note that we still don't have internal consensus on this PR; Yehuda was pretty concerned about it when we discussed it. I just put this up to make the discussion more concrete. |
ljharb
approved these changes
Sep 16, 2018
|
Achieved consensus at the September 2018 TC39 meeting. |
littledan
added a commit
that referenced
this pull request
Jan 9, 2019
This reverts PR #151. Rationale in #133 (comment)
littledan
added a commit
that referenced
this pull request
Jan 9, 2019
) This reverts PR #151. Rationale in #133 (comment)
littledan
added a commit
that referenced
this pull request
Jan 11, 2019
Initially, the decorators proposal had class descriptors which contained an elements array with public and private elements. Later, concerns were raised about exposing this private information unexpectedly (#133), and this access was removed (#151). However, this patch caused a problem: private field initializers were accidentally sorted after public field initializers, an observable and counterintuitive change (#183). Halfway solutions (#184) did not really work out; we added back the full element support in #133 (comment) . Although we believe that it makes sense for decorators to be able to see into class bodies, including private, and there are many important use cases (for both public and private, #192), this support doesn't have strict consensus in committee, so this patch serves as a conservative option in case including elements is unacceptable. This is not the preferred alternative, but it's a well-articulated backup plan. I'm writing this out in advance in the interest of time, to ensure that we have a path to Stage 3 and that this does not block things.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch makes it so that class decorators do not see private
class elements. With this patch, only element decorators have
the ability to do metaprogramming on private class elements.
For field/method decorators, granting access to the private name
seems syntactically clear and implied by the construct. There
are also several critical use cases, including:
@reader)@tracked)@testable)For access from class decorators to private, different people
have had different intuitions: Some expect access, while others
say it violates privacy. A workaround here, under this patch,
is to use an element decorator for each private element, rather
than a class decorator, to accomplish the same thing. This
may be ugly, but it works for all the use cases I'm aware of.
As a possible follow-on proposal, a specifically "trusted"
type of decorator could be created, though the details are unclear.
See #133