True literal types and union types for scala 3! #487
Conversation
|
Note that this branch relies on a fix for scala/scala3#16173 , so I used a locally built compiler which removes that particular check. |
|
Also props to @TheElectronWill who suggested this in #343 (comment) |
oyvindberg
force-pushed
the
master
branch
2 times, most recently
from
d3bbca8 to
ad9f226
Compare
On the scala side it's very, (, very, very) difficult to handle erasure of methods in the presence of many overloads, when useful information added by literal types. Especially if you want to consider inheritance hierarchies, maintain high fidelity translation, and make it usable for end-user. It's borderline impossible, which is why ST has used the fake literal types which invents fake traits for all the literals. Suffixing of overloaded methods has also been used (`createElement_div`, for instance) Now we use @TargetNAME to disambiguate overloads. *All* methods which has literal types will get a `targetName` will containing the method name and all container literals. Like before, `@JSName` will be used to communicate the original method name to Javascript Effectively, this creates a new namespace on the Scala side, and we can perform erasure checks like normal for all overloads with the same sequence of literals. It all seems to work out really well. ST has until now (best-effortly) translated union types into inheritance. This was done to make things usable. scalac and IDE performance suffered, and IDE tooling was helpless when confronted with Scala.js' userland union type. This has all changed, and it's incredibly liberating to finally remove this hack too.
oyvindberg
force-pushed
the
true-literal-and-union-types
branch
from
802a7e6 to
57a2058
Compare
|
preview of changes here ScalablyTyped/Distribution@dd3ce51 |
|
Amazing! scala/scala3#16173 is fixed in v3.2.1 :) |
deps:
"@emotion/react" -> "11.10.5",
"@emotion/styled" -> "11.10.5",
"@mui/material" -> "5.11.0",
"@mui/icons-material" -> "5.11.0",
"@types/react" -> "18.0.26",
"@types/react-dom" -> "18.0.9",
"@types/stylis" -> "4.0.2",
"react" -> "18.2.0",
"react-dom" -> "18.2.0"
Upgraded ST to 1.0.0-beta40
- includes " True literal types and union types for scala 3!" @ ScalablyTyped/Converter#487
- includes https://github.com/ScalablyTyped/Converter/tree/mui5-support
As a consequence this should be much, much nicer to use than before
|
Thank you for all the hard work you've put into this project 🙏 |
Thanks :) Yes, this will be merged eventually. The main thing it is missing is what to do about scala 2.13 where there is no `@targetName@ annotation. I'm deep in two other projects now, so this will be solved in the coming months. in the meantime you can |
I don't think much can be done in Scala 2, but that's not a big deal if the generated api is better for Scala 3, is it? |
|
Hello again! Still using a local build of this branch but now running into issues updating sbt: I don't really mind sticking with an older version of sbt, but that effectively ties me to an older JDK. I'm guessing this should do the trick, but also wondered if there's an update, even if the update is "no update" 😅 |
Kapture.2022-10-13.at.14.40.36.mp4
On the scala side it's very (, very, very) difficult to handle erasure of methods in the presence of many overloads, when useful information added by literal types. Especially if you want to consider inheritance hierarchies, maintain high fidelity translation, and make it usable for end-user. It's borderline impossible, which is why ST has used the fake literal types which invents fake traits for all the literals. Suffixing of overloaded methods has also been used (
createElement_div, for instance)Now we use
@targetNameto disambiguate overloads. All methods which have literal types will get atargetNamecontaining the method name and all the contained literals.Like before,
@JSNamewill be used to communicate the original method name to JavascriptEffectively, this creates a new namespace on the Scala side, and we can perform erasure checks like normal for all overloads with the same sequence of literals. It all seems to work out really well.
ST has until now (best-effortly) translated union types into inheritance. This was done to make things usable. scalac and IDE performance suffered before that hack, and IDE tooling was helpless when confronted with Scala.js' userland union type. This has all changed, and it's incredibly liberating to finally remove this hack too.