Hacker News Reader

Comment by nikeee | Hacker News Reader

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.

View on HN

Is there any non-primitive JS type that has non-referential equality for ==?

Yeah, 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)

There's exactly one IIRC. document.all

It 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.

Passing 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.

Even 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.

Because 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.

There is the record and tuple proposal. If we'd have methods on records (currently not part of the spec) this would be trivial.

I 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).

Why not just use 'String()' or '2020-01-01'?

Temporal 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.

Comparison functions are unlikely to work across libraries too?

I 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).

Reply on news.ycombinator.com