Let's say I have the following class: ```@JsExport...

# javascript

[Edoardo Luppi]

Let's say I have the following class:

@JsExport
class TestExport(val two: String) {
    var one: Int
        get() = 12
        set(value) {
            println("set one to $value")
        }
}

The outputted code is:

class TestExport {
  constructor(two) {
    this.two = two;
  }
  k1() {
    return this.two;
  }
  l1(value) {
    println('set one to ' + value);
  }
  m1() {
    return 12;
  }
  get one() {
    return this.m1();
  }
  set one(value) {
    this.l1(value);
  }
}

As you can see there is overlap between m1() and get one(), or l1() and set one().
We effectively have a public interface and a private interface used inside the Kotlin module. Question: is this by choice or is the simplification into one single merged interface not technically possible (or just too difficult)?

[Artem Kobzar]

Technically, it seems like we can merge them (I didn't find any case where it doesn't work), but we just need in all the overrides to write extra get/set keyword with full name, instead of a function with a minified name.

[Edoardo Luppi]

but we just need in all the overrides to write extra get/set keyword with full name, instead of a function with a minified name

Ah yup! Forgot about this and it's an interesting point. It does not impact only overrides, but also "internal" calls. If we have hundreds of calls of those getters and setters inside the Kotlin module, we might end up with a bigger bundle.