While in JVM it works, in JS it cause name collision: ```class A { val test: Any by lazy {...} f...

# javascript

[PHondogo]

While in JVM it works, in JS it cause name collision:

class A {
  val test: Any by lazy {...}
  fun test(): Any {...}
}

[Johann Pardanaud]

use @JsName 🙂

https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.js/-js-name/

[PHondogo]

Want to avoid such things.

[Johann Pardanaud]

you have no choice, because a method in JS is simply a property with a function as a value

[Johann Pardanaud]

which means you try to create two properties named test

[PHondogo]

That i understand. Wonder why than it allowed in Kotlin MPP. Better to rename function or propery in common code then.

[andylamax]

No way that is better. Introducing constraints of other platforms to common code is a poor approach in my opinion. Let kotlin be kotlin (as best as possible), if there are platform specific constraint, make it a language feature (e.g. using @JsName, or @JvmOverloads) to cater for the specific platform. But by no means, cripple the beauty of kotlin

[PHondogo]

Looks messy for my own opinion. It is not library specialization, it is the language future that pretend to be MPP.

[Piotr Krzemiński]

I get your point @PHondogo and I sometimes have this aftertaste as well. I’d like to just use Kotlin without polluting the common code with platform-specific annotations.

[Piotr Krzemiński]

What I’d expect in this very case (name clash) is using name mangling. If a given symbol needs to have a predictable name, then use @JsName

[PHondogo]

Yes. Language rules and common code must be common. And in case of need of exact name one should use annotation. Now it is upside down.