Closed
Description
Accessors in Object Types
- 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 likereadonly
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?
- Breaks some code that takes advantage of futzing with
- 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.
- But then you also need to be able to declare
- 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
- 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.
- But Lodash's mapValues and empty object type interact confusingly #29901 dated back to 3.3 and we fixed that! Similar issue.