5 ms·
I really like the temporal proposal, except for one thing: they rely on reference equality in comparisons. On other words: Temporal.Instant.from('2020-01-0
by nikeee 2y ago
I really like the temporal proposal, except for one thing: they rely on reference equality in comparisons. On other words:
Temporal.Instant.from('2020-01-01') != Temporal.Instant.from('2020-01-01')
This isnt inherently bad, but it effectively removes the ability to use these objects as Map keys or collecting them in a Set. I know why that decision was made, I'm just sad that this wont be possible. Maybe there will be some version that relies on records and tuples, if these ever make it.
- modeless 2y agoI guess this would require operator overloading. Is there a proposal for that? A JavaScript version of numpy/pytorch would also need overloading (plus array slicing).
- deleted 2y ago[deleted]
- brundolf 2y agoIs there any non-primitive JS type that has non-referential equality for ==?
- tubthumper8 2y agoYeah, that's one of the core problems, there's no overloading of equals in JS and no other cases of objects using non-reference equality. Adding that in itself would be a big deal (ex. see the Records and Tuples proposal which has been going on for years and may never complete)
- 8n4vidtmkvmk 2y agoThere's exactly one IIRC. document.all
- sureIy 2y agoWhy not just use 'String()' or '2020-01-01'?
- justingrantjg 2y agoTemporal includes `equals` methods on every type. String comparison sometimes works, but there are enough cases where it doesn't (especially when comparing strings that refer to the same data but were generated by different libraries so formatting is different for things like trailing zeroes of decimals, time zone aliases, etc.) that it's usually best to use a library function for comparison instead of just using string comparison.
- 8n4vidtmkvmk 2y agoComparison functions are unlikely to work across libraries too?
- syncsynchalt 2y agoIt looks like `.epochMilliseconds` should work as a Map/Set key/member in some situations, though you'll need to preserve the instant in the value in the Map case if you want to preserve the zonedata / do further operations on the Instant. For the Set case you could use a Map{v.epochMilliseconds:v} and preserve the Instant. Not great, but I think we all blame JS for this rather than Temporal. This could be made to work by the runtime but then polyfills would fail.
- nikeee 2y agoPassing Dates to a React component caused re-rendering issues in some of my applications due to Date being an object. I had to resort to numbers (Unix time) to not have to add memoization everywhere. Seems like this will continue with Temporal. Or React-Compiler will solve this.
- ivanjermakov 2y agoBecause it is impossible in JS? Except some crazy hacks, similar to how Java's constant string pool works, where every used object is a reference to a value in a pool of all objects.
- jdkoeck 2y agoI wouldn’t call this a particularly crazy hack, it’s also called string interning and I reckon that’s what every language runtime does when strings are immutable (which includes javascript runtimes, also this isn’t required by the language specification).
- nikeee 2y agoThere is the record and tuple proposal. If we'd have methods on records (currently not part of the spec) this would be trivial.
- zeroimpl 2y agoEven if that worked, using these in a map/set would be a lot like using floating point numbers in a map/set - which is generally a bad idea.