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

Design Meeting Notes, 9/6/2024 #60282

Open
DanielRosenwasser opened this issue Oct 18, 2024 · 0 comments
Open

Design Meeting Notes, 9/6/2024 #60282

DanielRosenwasser opened this issue Oct 18, 2024 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Consistency for Computed Properties in Classes

#59860

  • Working on making computed properties work consistently between source files and declaration files.
  • In object literals, anything goes.
  • In classes, they do not behave the same.
    • We error if a computed property doesn't resolve to a specific well-known symbol, unique symbol, or literal type.
    • For computed methods.... we say nothing?
  • Want to make classes consistent with object literals.
  • This PR just fixes computed
  • Downsides?
    • It breaks code (obviously).
    • Still need to run on top codebases.
  • Does this just change classes, or also interfaces?
    • Just classes.
  • Do we really need to adopt the behavior where it produces index signatures?
    • It's the only thing that has consistent behavior for isolated declarations?
  • What if you have multiple computed properties with different types?
    • Just use the union of the types in a single index signature, but not necessarily the best behavior we could do - would be a follow up.
    • Can have multiple index signatures these days, so maybe we just produce multiple index signatures.
  • What happens if you don't know the type?
    • Just create a string index signature right now so that it's consistent with object types.
  • Do you really want these index signatutes?
    • In the object literal case, there is no way to add an index signature to the object literal.
    • But a class is sort of used as a hybrid between a JavaScript value declaration and a TypeScript type.
  • We like consistency, but feel a little shaky about just introducing index signatures (the follow-up).
    • Can do that behavior, but can still error possibly?

Node, Type, and Signature monomorphization

  • Make AST nodes monomorphic. #59190
  • Make types monomorphic #59191
  • Make Signature monomorphic #59192
  • Moves non-monomorphic properties to a data grab-bag
    • Causes v8 to optimize this correctly
  • getters/setters in the prototype chain expose the data. properties for compatibility
    • You can put arbitrarily many getters in the same chain for convenience since they're 1:1
    • We still go through these in this PR and see wins; we could go to .data instead and likely get faster?
  • Big big big speedup, slightly more memory usage
  • Concern: all these properties show up in a debugger
    • API consumers will see all these properties too; implications for in
    • Can we provide API users with a more-specific facade?
      • Work in progress, numbers on this approach soon
  • Conclusion: Check on Ron's version and merge whatever looks best overall
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Oct 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

1 participant