Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop representing quoted member functions as computed properties in the AST #3071

Open
lauraharker opened this issue Sep 12, 2018 · 1 comment
Labels
internal cleanup internal-issue-created An internal Google issue has been created to track this GitHub issue P3 triage-done Has been reviewed by someone on triage rotation.

Comments

@lauraharker
Copy link
Contributor

Filing this after internal discussion with @concavelenz

Right now the compiler represents quoted member functions, e.g. class C { 'f'() {} }, the same way it represents computed property member functions: class C { ['f']() {} }.

This means that the compiler prints class C { ['f']() {} } if given class C { 'f'() {} }: example.

This does not align with how we treat quoted regular object literal properties, getters, and setters. Those have a special 'quoted_prop' attribute to store whether they were originally quoted or not.

public boolean isQuotedString() {

Computed properties/getter/setters are stored differently in the AST.

We probably want to revisit this decision at some point:

  1. it's confusing to have different behavior for member functions and regular properties/getters/setters.
  2. @concavelenz suggested that (paraphrasing): we want the AST for quoted member functions to maintain the code's original structure, even though they are conceptually similar to computed properties. we also already have a concept of a quoted property.
@lauraharker
Copy link
Contributor Author

Created internal issue http://b/123769080

@lauraharker lauraharker added triage-done Has been reviewed by someone on triage rotation. internal-issue-created An internal Google issue has been created to track this GitHub issue labels Feb 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
internal cleanup internal-issue-created An internal Google issue has been created to track this GitHub issue P3 triage-done Has been reviewed by someone on triage rotation.
Projects
None yet
Development

No branches or pull requests

1 participant