https://kotlinlang.org logo
#javascript
Title
# javascript
p

PHondogo

02/01/2023, 8:48 AM
While in JVM it works, in JS it cause name collision:
Copy code
class A {
  val test: Any by lazy {...}
  fun test(): Any {...}
}
j

Johann Pardanaud

02/01/2023, 9:26 AM
p

PHondogo

02/01/2023, 9:28 AM
Want to avoid such things.
j

Johann Pardanaud

02/01/2023, 9:30 AM
you have no choice, because a method in JS is simply a property with a function as a value
which means you try to create two properties named
test
p

PHondogo

02/01/2023, 9:32 AM
That i understand. Wonder why than it allowed in Kotlin MPP. Better to rename function or propery in common code then.
a

andylamax

02/01/2023, 9:37 AM
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
👍 1
💯 3
p

PHondogo

02/01/2023, 9:44 AM
Looks messy for my own opinion. It is not library specialization, it is the language future that pretend to be MPP.
p

Piotr Krzemiński

02/08/2023, 10:45 AM
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.
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
p

PHondogo

02/08/2023, 10:49 AM
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.
👍 1
5 Views