https://kotlinlang.org logo
Join Slack
Powered by
I recently started looking at Kotlin/JS and I'm cu...
# javascript
l
I recently started looking at Kotlin/JS and I'm curious as to why extension functions are not translated using object prototypes. I've seen https://youtrack.jetbrains.com/issue/KT-11681 but that does not give an explanation either. Was this a deliberate design decision or has this just never been implemented?
e
Ext functions are resolved statically
l
@elizarov Only top level ones (which is most of them), right?
l
Would it be feasible to add something like a 
@JsPrototype
annotation, or does that violate the spec for extension functions too much?
e
All are resolved statically with respect to their extension receiver (dispatch receiver can be dynamic, true)
👍🏽 1
Making it dynamically dispatch would break Kotlin language semantics.
Since we are friends here, I'll be frank with you. A feature where an extension can just modify object's prototype is an extremely bad idea from the language design standpoint. It is a canonical example of how a language should never work. Have you been even bitten by a 3rd party JS library that hacked object prototypes so that your tried and tested and unreleated code does not work anymore?
👍 1
➕ 5
l
No, I have actually not had this issue yet. I tend to avoid JS as much as possible (not a fan of dynamic typing) and I am looking at Kotlin/JS as a substitute or slow transition to JS. This question was really more about exploring and understanding design decisions (since I have seen extensive use of prototype objects in libraries and thought it is common practice) than giving an opinion. I really appreciate your straightforwardness and will keep this in mind. 🙂
f
prototype functions are always in global scope
And for me, the beauty of extension functions comes from their ability to be local
in global scope
More precisely, in the same scope where the extended "class" is declared
Open in Slack
PreviousNext
Powered by