I wonder what's the best way to deal with such a t...

# javascript

[Edoardo Luppi]

I wonder what's the best way to deal with such a thing when translating from TS:

interface One {
  prop: BaseType
}

interface Two extends One {
  prop: RefinedType // extends BaseType
}

[Artem Kobzar]

https://pl.kotl.in/j2ni1UyDp

external open class BaseType
external class RefinedType : BaseType

external interface One {
    val prop: BaseType
}

external interface Two : One {
    override val prop: RefinedType
}

Doest the direct option work?

[Edoardo Luppi]

@Artem Kobzar works! But now I understand that it works when prop is val, and not when prop is var, which is the most common case

[Edoardo Luppi]

So this won't compile

external open class BaseType
external class RefinedType : BaseType

external interface One {
    var prop: BaseType
}

external interface Two : One {
    override var prop: RefinedType
}

[Edoardo Luppi]

I'd add this to what a JsPlainObject could be able to do 👀 just an hint

[Artem Kobzar]

Yes, because TypeScript is not sound at all: https://www.typescriptlang.org/play?#code/MYGwhgzhAEBCkFMAqBPADg6BvAvgKFEhgCUEAzASwDsEATVDa[…]WSSIlYZEHSaQAbjwxwQpwutGut3urXqMKawWk5mR1Msn0WanEUmkQA

[Artem Kobzar]

We can't bring this functionality because it breaks Kotlin type system correctness

[Edoardo Luppi]

Ah makes sense! Maybe we can make it work with a val and a custom inline set* method that write to the underlying property?

But would methods work with the new plain objects?

[Artem Kobzar]

I mean, it will work in case of creating object, but not for the future mutating of the property

[Artem Kobzar]

@JsPlainObject
external interface One {
    val prop: BaseType
}

@JsPlainObject
external interface Two : One {
    override val prop: RefinedType
}

One(BaseType()) // works
One(RefinedType()) // works
Two(RefinedType()) // works
Two(BaseType()) // Compile-time error

Two(RefinedType()).apply { prop = RefinedType() /* Compile-time error, because you can't mutate the property */ }

Two(RefinedType()).copy(prop = NewRefinedType()) // works

[Edoardo Luppi]

To be clear I'm suggest going from

external interface One {
    var prop: BaseType
}
external interface Two : One {
    override var prop: RefinedType
}

to

external interface One {
    val prop: BaseType
    open inline fun setProp(p: BaseType): Unit = asDynamic().prop = p
}
external interface Two : One {
    override val prop: RefinedType
    override inline fun setProp(p: RefinedType): Unit = asDynamic().prop = p
}

[Edoardo Luppi]

More or less I guess you can understand where I'm going

[Edoardo Luppi]

I need to check if it compiles tho

[Edoardo Luppi]

Ah nope, it doesn't compile

[Edoardo Luppi]

I recalled I did something similar, but it was on an external class, not an interface

[Edoardo Luppi]

What if you introduce an additional copy function that doesn't create a new object?

val modified = Two(RefinedType()).modify(prop = NewRefinedType())

At this point I'm just throwing ideas around lol

[turansky]

In case of JSO var has no big sense.
In wrappers we plan to use val for JSO-interfaces even if in TS it's declared as mutable property.

P.S. Props - open question

[turansky]

Nearest Kotlin analog - data class.
I usually don't use var in data classes and use readonly JSO in TS.
Both have fine copy methods/syntax.

cc @Sergei Grishchenko

[Edoardo Luppi]

Yeah I agree that val is usually better.

But, I'd like to have a way to mutate the object without performing a copy of it every time. See example I made above

[turansky]

No problem, use var for your properties.
Additional bonus - inheritance problems :)

[Edoardo Luppi]

I think it depends on the use case, there are sensible places where performing a copy isn't the best choice, hot paths where you want the performance boost, like with avoiding null checks and deep call stacks

[turansky]

Yes, looks like case for var