|
due to their null-safety (which on its own is redundant: the jvm spits nullpointer exception upon access of a nullpointer already), they generate null checks in about every statement (first accesses primarily), but to take it a step further, their optimization in most range and for-operations is non-existent (you can check some cases by compiling and then using `javap -c ClassName` to inspect the generated code).
things like "inline classes" rarely get inlined (in your codebase you have inline classes for ZoneUnit if I'm not mistaken which do not get inlined and will in the runtime be real allocs) and operator overloads with simple bytecode ops become real method calls with all associated overhead instead of "IADD", or similar
I think the null-safety in Kotlin is probably one of its strengths. The fact that it is redundant doesn't matter. Every language has concepts that are redundant, but just make it easier for the developers.
This is the first time I heard about the for-operations/ranges issue. I tried some simple cases and couldn't find any evidence of this.
That's not true. Also, inline classes are experimental and will improve in 1.5.things like "inline classes" rarely get inlined (in your codebase you have inline classes for ZoneUnit if I'm not mistaken which do not get inlined and will in the runtime be real allocs)
how is it redundant to turn a problem that was traditionally found at runtime into a compile time problem..?
this is only true if you don't understand the limitations of inline classes. i've inlined plenty, e.g. the Position/Coord class can be inlined and backed by a simple Int, and confirmed that all usages of it have definitely been inlined by decompiling the resultant bytecode.
« Previous Thread | Next Thread » |
Thread Information |
Users Browsing this ThreadThere are currently 1 users browsing this thread. (0 members and 1 guests) |