4 ms·

While that could help, I don't see why records and tuples are necessary. We added symbols precisely to deal with this issue in a backward compatible way. We cou

by spion 3y ago

While that could help, I don't see why records and tuples are necessary. We added symbols precisely to deal with this issue in a backward compatible way. We could add symbols for set/map protocols using `equals` and `getHashCode` which would enable any objects to get set/map deduplication functionality. Those implementation could then be the mechanism how its implemented for records and tuples. If this is a bad way to do it, then why isn't TC39 working on a better way to implement protocols / traits in JS?

spion 3y ago
relevant issue, which is at the crux of this problem: https://github.com/tc39/proposal-record-tuple/issues/387 https://github.com/tc39/proposal-record-tuple/issues/387 and which shows that a symbol based protocol was the kind of approach that could've worked from the start. See `Symbol.keyEquality` - although that still shows what I feel is a misunderstanding about the direction at which the protocol should work. I don't want to be creating new types of maps and sets, I want existing ones to have controllable key equality. If it was for new types of maps and sets, I'd just implement a new Set class independent of JS builtins and be done with it. (Its not like the built in Set offers any rich features that I'd have a hard time replicating anyway) Protocols (traits) should really be the cornerstone of TC39 work, IMO. They'll help with JavaScript's serious ecosystem compatibility issues.