Current approach has some drawbacks.
We cannot use kotlin object as DTO (data transfer object) because js side cannot use any properties from it. JS side (i.e. hand-written js code) or native side (browser extension or server side) try to get property “a” from passed object, but actually it is a function “get_a()”
It is main reason to start this discussion, but there are many other advantages — debuggable and readable code.
http://kangax.github.com/es5-compat-table/
Browser compatibility — if defineProperties is not supported (https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Object/defineProperties) we can fallback to getters/setters (https://developer.mozilla.org/en/JavaScript/Reference/Operators/get)
Current approach is needed only if user want compatibility with IE <8, but in any case we must generate more simple JS code — if kotlin var doesn’t define getter/setter, so, don’t generate getter/setter for it.
What do you think about it? Do you have any plans about it?
Hi, thanks for feedback.
Sadly, I’m not really an expert at JavaScript compatability issues, so I went the easiest (at least I thought it was) road. So, any suggestions are welcome.
As for this particular issue(keeping properties simple) we have to remember a couple of things:
- Any property can have custom accessors.
- Any open property’s accessors can be overridden.
- A class can be inherited from multiple traits (and a single class) defining the same property (and possibly some of them defining accessors).
If all these issues can be solved using simpler and more “JavaScript friendly” approach then we should definitely do it.
Anyway, I see you already took a stab at it so I should probably get to reviewing your pull request.
Yes, all these issues can be solved using JavaScript 1.8.5 (Ecma 5). My patch doesn't solves these issues and, currently, just ignore it (as you can see in my pull request comment). I think, user can select target — use ecma 3 (current, by default) or ecma 5. I am going to implement more ecma 5 translation on next weekends (ecma 5 is also ugly and boring but in any case it provides more better way to to define classes and class members).
Can you explain me problem "hasNext" as function vs hasNext as getter? I don't understand this mess. There are only some tests failed for ecma 5 — due to hasNext and extension to kotlin classes. I know how to fix extensions, but I cannot fix hasNext problem without your advice.
What is problem — we cannot have hasNext as function and hasNext as getter for ecma 5, because we use native getters (opposite to ecma 3) — get_hasNext. So, we should use only one way — or function, or getter.
What is correct?
I do not get the context of your problem completely. Do you refer to kotlin_lib.js? Or kotlin conventions in general?
Kotlin conventions are that it can be either a function or a property (dunno what happens when there are both).
Kotlin JavaScript library has kinda messy code so you are welcome to hack it.
Or do you refer to the problem “How do I tell what code should I generate when I see foreach loop”?
Please provide more information.
P.S. One important thing I wanted to point out is as far as I understand that in both Ecma3 and Ecma5 extension properties must be functions (they can be virtual, they can be have the same name in different packages).
>> dunno what happens when there are both
it is not working (ecma 5), because we cannot define function hasNext and define getter hasNext (and kotlin also doesn't allow to have "val hasNext" and "function hasNext" in the same class).
Ok. I will fix StandardClassesTest#testArraysIterator and prefer getter to function.
>> One important thing I wanted to point out is as far as I understand that in both Ecma3 and Ecma5 extension properties must be functions
Yes, indisputable. Because we need pass receiver param (almost in all cases it will be “this”) — change class prototype is not good idea.