Name overrides are one thing, and you could provid...

# multiplatform

[eddie]

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?

[Ruckus]

For example, say I have the following in a common module:

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?

[eddie]

• Define these in the platform modules instead
• Wait for the JVM to support reified generics
• Name-mangling

[eddie]

Or, instead of the first option, support applying annotations to previously-defined common entities in platform modules (a la external annotations)

[agrosner]

Things like annotations for annotation processing keep it concise without need to essentially duplicate a class accross android and jvm implementation too

[Ruckus]

@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.

[Ruckus]

...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.

[Ruckus]

Basically, I don't think of common modules as a method of implementation abstraction so much as a code-reuse pattern.