https://kotlinlang.org logo
#multiplatform
Title
# multiplatform
e

eddie

08/01/2018, 7:33 PM
Name overrides are one thing, and you could provide a generic
@TargetName
annotation for that. I'm referring more to also exposing things like @JvmField, @JvmStatic, @JvmOverloads, etc. Why do those belong in common code?
r

Ruckus

08/01/2018, 7:39 PM
For example, say I have the following in a common module:
Copy code
fun List<Vector2>.bounds() = ...
fun List<Vector3>.bounds() = ...
Kotlin can handle those two functions just fine, but they cannot be statically resolved on the JVM, so I want them to be renamed (only on the JVM) to
bounds2d()
and
bounds3d()
. How would I do that if I can't use the annotation in common code?
e

eddie

08/01/2018, 7:52 PM
• Define these in the platform modules instead • Wait for the JVM to support reified generics • Name-mangling
Or, instead of the first option, support applying annotations to previously-defined common entities in platform modules (a la external annotations)
a

agrosner

08/01/2018, 8:33 PM
Things like annotations for annotation processing keep it concise without need to essentially duplicate a class accross android and jvm implementation too
r

Ruckus

08/01/2018, 10:13 PM
@eddie That would add a severe degree of complexity if you ask me. If they are pure Kotlin code defined in a common module, it would be a pain to have to maintain them in multiple modules purely for the sake of naming, when you're not really changing the implementation at all.
...wouldn't that indicate that you're exposing implementation details that should be kept within the respective platform modules?
When it comes right down to it, I guess I don't agree with this claim, but I may just have a different way of looking at it.
Basically, I don't think of common modules as a method of implementation abstraction so much as a code-reuse pattern.
3 Views