Skip to content

Design Meeting Notes, 12/16/2020 #42194

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

Closed
DanielRosenwasser opened this issue Jan 3, 2021 · 0 comments
Closed

Design Meeting Notes, 12/16/2020 #42194

DanielRosenwasser opened this issue Jan 3, 2021 · 0 comments
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

Accessors in Object Types

#40733

  • Existing libraries/frameworks that uses accessors and meta-programming to create classes from objects.
  • Uses mapped types, but mapped types don't preserve accessor-ness.
  • Could potentially have get/set modifiers in mapped types, just like readonly for readonlyness and ? for optionality.
    • { +get [K in keyof T]: T[K] }
  • Proposal in TC39 that's championing get/set - probably should be mindful of that.
  • Set vs. Define? The error given here stemmed from adding "define property" semantics.
    • Unclear - the error is actually pretty useful.
    • Well...
  • Probably going to special-case this as a check for whether the property originates from a class.
  • Special-casing to classes seems okay - but this sounds like it's just a case of prototype vs. instance, and accessors are just a proxy for prototype vs. instance in this case.
  • virtual? Some sort of intention?
  • "I don't think Daniel is entirely incorrect" about prototype vs. instance
    • [[Editor's Note: This is a very proud day for me.]]
  • How do you track this?
    • prototype property of the class.
    • Maybe find a way to make that work for non-class things.
    • Could end up just being as bad of a heuristic of being on prototype as accessors
  • If you try to track the prototype property...
    • Breaks some code that takes advantage of futzing with .prototype
    • Potentially makes code "more nominal" - now have to differentiate between proto and instance?
  • Sounds like the safest thing is to do the class thing.
    • It's not safer!
    • It's safer for us to not get yelled at. 😄
  • How common are class factories nowadays?
    • Well... people end up writing functions and classes that wrap other classes.
  • One big problem is that people want safety, but you're not giving them the ability to "do the right thing" in a mapped type.
    • But then you also need to be able to declare get/set in object types - the original topic for today.
  • Curious to see what inferring getters/setters would do in terms of breaking changes, but not a trivial change.
  • As hard as it is to model, it would potentially be helpful.
  • Conclusion: discuss viability of a prototype.

Reducing Bivariance Checks

#41979

  • Under strictFunctionTypes, one would think that the original code snippet has an error.
  • Somehow, either swapping the elements of the array, or introducing a type alias, introduces an error!
    • Very unpredictable behavior!
  • Two types going into the subtype reduction.
    • Unions are ordered by type ID.
    • Insert a type alias, and you'll force the introduction of a new type for the later-declared property.
  • The problem comes down to how our subtype relationship should introduce a total ordering (whereas our assignability doesn't necessarily need that).
  • Aside: is this related to classes?
    • Probably not.
  • We tried to fix this and caused one break in our own codebase.
  • Not non-deterministic, it's just unpredictable/chaotic.
    • "butterfly effect" breaks.
    • Breaks incremental mode.
      • Can happen in the wild, ruin people's day.
  • Seems like subtype relationship should work regardless of strict function types on.
  • This dates back to 3.3 - doing nothing is on the table.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Jan 3, 2021
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