3 ms·

Yup. I don't find myself using classes much, but some of the other new features remove the vast number of issues you tend to face. Is scoping an issue for you?

• recursive 6y ago
  I use classes a fair amount, but there's still some weird stuff in the language I'd take out if I could. Sparse arrays, all object keys are strings (or symbols), crazy coercion rules, the existence of `null`, weird float vs int rules.
  • runarberg 6y ago
    You can use `Map` instead of object which allows keys of any type, or typecheck your objects with `Record<K, V>` and let typescript warn you about any weirdness. Typescript can also warn you if you do some weird implicit coercion. You can typeguard against `null` (although I admit it is annoying, I just want to use an optional†). And if you really want to use integer types there is always `BigInt`. --- †: I haven’t checked, but I bet there are some libraries out there that provide proper optionals using Proxy.
    • recursive 6y ago
      I use BigInt often, but you can't (for example) do most substring operations with it, even though floating point indexes make no sense. Map goes part of the way to what I want. But I really want to control which objects are considered equivalent keys, rather than being limited to reference equality.
      • WorldMaker 6y ago
        There's a Stage 2 proposal before TC-39 to add immutable Record and Tuple types [1] which would be structurally compared and perfect for complex Map keys. It's also easy enough to find or write quick simple Map wrappers that use a hash function on an object as keys when provided (either piggy-backing on the existing Object.prototype.valueOf, which always exists on every object and easily falls back to the reference-based current behavior, and expecting classes to have custom overrides for that, or using a Symbol named function of their own to avoid polluting own-property-keys/name clashes with other libraries). [1] https://github.com/tc39/proposal-record-tuple https://github.com/tc39/proposal-record-tuple