Private-named instance fields#32
Merged
Neuroboy23 merged 6 commits intobloomberg:private-named-instance-fieldsfrom Apr 3, 2019
Merged
Private-named instance fields#32Neuroboy23 merged 6 commits intobloomberg:private-named-instance-fieldsfrom
Neuroboy23 merged 6 commits intobloomberg:private-named-instance-fieldsfrom
Conversation
a97aa6b to
ecd1529
Compare
This was referenced Mar 27, 2019
Signed-off-by: Joseph Watts <jwatts43@bloomberg.net>
and check that private names not used in parameters Signed-off-by: Max Heiber <max.heiber@gmail.com>
Signed-off-by: Joseph Watts <jwatts43@bloomberg.net>
Signed-off-by: Joseph Watts <jwatts43@bloomberg.net>
- [x] treat private names as unique:
- case 1: cannot say that a variable is of a class type unless the variable points to an instance of the class
- see [test](https://github.com/mheiber/TypeScript/tree/checker/tests/cases/conformance/classes/members/privateNames/privateNamesUnique.ts)
- case 2: private names in class hierarchies do not conflict
- see [test](https://github.com/mheiber/TypeScript/tree/checker/tests/cases/conformance/classes/members/privateNames/privateNamesNoConflictWhenInheriting.ts)
- [x] `#constructor` is reserved
- see [test](https://github.com/mheiber/TypeScript/tree/checker/tests/cases/conformance/classes/members/privateNames/privateNameConstructorReserved.ts)
- check in `bindWorker`, where every node is visited
- [x] Accessibility modifiers can't be used with private names
- see [test](https://github.com/mheiber/TypeScript/tree/checker/tests/cases/conformance/classes/members/privateNames/privateNamesNoAccessibilityModifiers.ts)
- implemented in `checkAccessibilityModifiers`, using `ModifierFlags.AccessibilityModifier`
- [x] `delete #foo` not allowed
- [x] Private name accesses not allowed outside of the defining class
- see test: https://github.com/mheiber/TypeScript/tree/checker/tests/cases/conformance/classes/members/privateNames/privateNameNotAccessibleOutsideDefiningClass.ts
- see [test](https://github.com/mheiber/TypeScript/tree/checker/tests/cases/conformance/classes/members/privateNames/privateNamesNoDelete.ts)
- implemented in `checkDeleteExpression`
- [x] Do [the right thing](https://gist.github.com/mheiber/b6fc7adb426c2e1cdaceb5d7786fc630) for nested classes
mv private name tests together
more checker tests for private names
update naming and cleanup for check private names
for private name support in the checker:
- make names more consistent
- remove unnecessary checks
- add utility function to public API
- other small cleanup
Move getPropertyNameForUniqueESSymbol to utility
for consistency with other calculation of
special property names (starting with __),
move the calculation of property names for
unique es symbols to `utilities.ts`.
private name tests strict+es6
Update private name tests to use 'strict'
type checking and to target es6 instead of
default. Makes the js output easier to read
and tests more surface area with other
checker features.
error message for private names in obj literals
Disallow decorating private-named properties
because the spec is still in flux.
Signed-off-by: Max Heiber <max.heiber@gmail.com>
Implements private instance fields on top of the class properties refactor. Signed-off-by: Joseph Watts <jwatts43@bloomberg.net> Signed-off-by: Max Heiber <max.heiber@gmail.com>
ecd1529 to
3f6b68f
Compare
Neuroboy23
reviewed
Apr 1, 2019
| const containingClass = getContainingClass(name.parent); | ||
| if (!containingClass) { | ||
| // we're in a case where there's a private name outside a class (invalid) | ||
| return undefined; |
There was a problem hiding this comment.
I see that this is the only explicit return value of undefined. Any other undefined would have to come from an inner method call. I see some existing calling code that does things like !getDeclarationName(...). Does this undefined value here mean the same thing as any other potential undefined values? If not, maybe it's better to throw here (explicitly or implicitly) instead?
Author
There was a problem hiding this comment.
@Neuroboy23 these changes were reviewed internally months ago and also given a peruse by Daniel and Ron. I'm open to revisiting this after we open the PR against the MS TS repo.
Author
There was a problem hiding this comment.
Re this specific question:
- a private name outside a class body is a parse error and will be caught by the parser. If the user has noEmitOnError: false in their compilerOptions then we have to do best-effort on the emit, even though the emit almost certainly bad. In this case, I'm not sure whether it would be better to return
nodeorundefined.
Neuroboy23
approved these changes
Apr 3, 2019
This file contains hidden or 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
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.
Private-Named Instance Fields
This PR implements part of the tc39 class fields proposal for TypeScript. It includes:
Example:
ts
js
This PR includes work by the following engineers: