ts2kt
ts2kt copied to clipboard
Fix overriding of equals, hashCode, and toString to always compile
Fixes https://github.com/Kotlin/ts2kt/issues/106
Let's discuss. It seems to me that we should learn some to deal with such methods somehow other then just ignoring signature declared and substituting by our signatures - just for the sake of everything being compiled. May be even this issues should be address in kotlin compiler (where we can have aliases for external "system" names).
It turns out that we already can do this, however may be we don't need to do even that. I'm copying example from the bug reported so we can discuss if here:
Example:
declare class ExpectedOverrides {
equals(a);
hashCode(): number;
toString();
}
becomes:
external open class ExpectedOverrides {
override fun equals(a: Any): Unit = definedExternally
override fun hashCode(): Number = definedExternally
override fun toString(): Unit = definedExternally
}
Actually this will compile:
external open class ExpectedOverrides {
fun equals(a: Any): Unit = definedExternally
override fun hashCode(): Number = definedExternally
override fun toString(): Unit = definedExternally
}
So the only wrong override here is for equals
When I created an example.kt file with
external open class ExpectedOverrides {
fun equals(a: Any): Unit = definedExternally
override fun hashCode(): Number = definedExternally
override fun toString(): Unit = definedExternally
}
it failed with:
ts2kt$ ./gradlew build
e: /home/eric/PabstSoftware/git/ts2kt/src/main/kotlin/example.kt: (3, 30): Return type of 'hashCode' is not a subtype of the return type of the overridden member 'public open fun hashCode(): Int defined in kotlin.Any'
e: /home/eric/PabstSoftware/git/ts2kt/src/main/kotlin/example.kt: (4, 30): Return type of 'toString' is not a subtype of the return type of the overridden member 'public open fun toString(): String defined in kotlin.Any'
> Task :compileKotlin2Js FAILED
You mention "just for the sake of everything being compiled". I see it as CRITICAL that the output of ts2kt compile. If that is not the case, then the output must be hand-modified to achieve a buildable project. The vision of providing these automatically (via a repository or on-demand generation) will fail miserably if they don't compile. Considering that projects generally only use a small percentage of an API, it would be better for it to be simply dropped from the "external" declarations than not compile. In my understanding, almost ANYTHING is better than causing compilation errors.