Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Constructor inheritance #248

Closed
randombyte-developer opened this issue Mar 29, 2020 · 3 comments
Closed

Constructor inheritance #248

randombyte-developer opened this issue Mar 29, 2020 · 3 comments
Labels
critical kotlin-design limitations due to the design of kotlin language unusable-code kotlin code is generated, can be compiled but actually is unusable
Milestone

Comments

@randombyte-developer
Copy link

I am running dukat version 0.0.28.

export class A {
  constructor(p1: string) { }
}

export class B extends A { }

produces

external open class A(p1: String)

external open class B : A

Is this correct? I think the class B should also have the constructor from A.

I just tried to start with Kotlin JS and use a JS library in Kotlin, but noticed that the type hints were wrong.

@Schahen
Copy link
Contributor

Schahen commented Mar 29, 2020

Hi! I'm not sure, let's discuss.
Strictly speaking your code is out of scope of current kotlin functionality since it's not a declaration - as of now we support only declaration conversation.

So, let's modifiy slightly the example and consider this snippet of code:

declare class A {
  constructor(p1: string)
}

declare class B extends A { }

This is translated to (I'm omitting imports and annotations):

external open class A(p1: String)

external open class B : A

Which is perfectly valid in that sense that it will compile.
However! In typescript we can use A and B declarations following way:

function main() {
        let a = new A("HEY! I AM A");
        let b = new B("HI! I AM B");
}      

while in Kotlin this won't compile:

fun main() {
  val a = A("HEY! I AM A")
  val b = B("HI! I AM B")
}

So this do feels like a problem to me. Let me think about it for a while and double-check typescript specs.

If it is indeed a problem, it's definitely a major one - currently we check compilation errors but runtime errors will fly under our radars.

@Schahen Schahen added the kotlin-design limitations due to the design of kotlin language label Mar 29, 2020
@randombyte-developer
Copy link
Author

randombyte-developer commented Apr 7, 2020

Sorry for the late reply.

The defintion file I wanted to use is https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/google.visualization/index.d.ts

There's a lot of inheritance going on, specifically the charts don't explicity define constructors but inherit them.
I think that this is something that should definitely be supported.

@Schahen Schahen added unusable-code kotlin code is generated, can be compiled but actually is unusable and removed initial-investigation labels Apr 8, 2020
@Schahen Schahen modified the milestones: 0.5.1, 0.5.2 May 29, 2020
@Schahen Schahen modified the milestones: 0.5.2, 0.5.3 Jun 13, 2020
@Schahen Schahen modified the milestones: 0.5.3, 0.5.8 Aug 10, 2020
Schahen added a commit that referenced this issue Aug 21, 2020
@Schahen
Copy link
Contributor

Schahen commented Sep 8, 2020

Will be released in 0.5.8 now can be checked with dukat@next

@Schahen Schahen closed this as completed Sep 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
critical kotlin-design limitations due to the design of kotlin language unusable-code kotlin code is generated, can be compiled but actually is unusable
Projects
None yet
Development

No branches or pull requests

2 participants