undefined | Better HN

0 pointslomnakkus10y ago0 comments

> Why is reinventing the wheel considered a good thing?

It's not. There just is no shim for java.time currently! Even worse, there could be licensing issues[1].

EDIT: That, and some of us are unfortunately still on JDK7 until the next Ubuntu LTS. Not that that's scala.js's fault, but it's a practical issue.

EDIT: ... and of course having a duplicate implementation of java.time (JDK + the shim-which-is-basically-a-reimplementation-in-JS) could be considered "reinventing the wheel"! :) If you have to reinvent the wheel, then doing it such that it at least behaves completely consistently across all backend platforms is preferable, IMO.

[1] https://github.com/scala-js/scala-js/issues/1618

0 comments

3 comments · 1 top-level

justthistime_10y ago· 2 in thread

As mentioned in the ticket, the original implementation is BSD.

Your last point is not the only thing that matters though. If the runtime already ships with packages X, there is no point in shipping your own implementation.

(Which is exactly what Scala/Scala.js does with math stuff: it reuses BigInteger from the runtime on the JVM, but ships its own implementation with Scala.js.)

lomnakkusOP10y ago

Right, but the JS and JVM runtimes have quite different behavior. And I'm willing to bet that implementing something as non-trivial as java.time again in Scala(.js) will end up causing quite a few bugs because they aren't identical.

That's why I'd rather have a single implementation for anything non-trivial and just retarget that to each backend using more low-level primitives. After all you're using a different language -- using a different date/time API shouldn't be much of a problem.

justthistime_10y ago

Yeah, inventing an API and implementation of a date/time/calendar library from scratch without an existing spec, implementation, tests or experience will surely be totally bug-free.

1 more reply

j / k navigate · click thread line to collapse