Another question: We have some class names in diff...

# multiplatform

[Neal Sanche]

Another question: We have some class names in different packages in our KMM library that are the same, and on iOS these appear with underscores after them. For example, we have a GraphQL generated class called MonetaryValue. We thought we would hide these by making domain classes, in a 'models' package, with the same name, and just do some straight copying of the GraphQL classes into these. KMM seems to be taking the duplicate names and adding underscores. So we have MonetaryValue which is the GraphQL class. MonetaryValue_ which seems to be the data class we want. But then there's also a MonetaryValue__ which is an @interface that has a bunch of swift attributes like component1() and component2() and properties for the actual interesting data class things. Is the way all of this works documented somewhere? Or can someone explain this? Is there a way to change this behaviour? Thanks for any and all insights.

[Neal Sanche]

I did find this:

Objective-C does not support packages in a framework. Thus, the Kotlin compiler renames Kotlin classes which have the same name but different package in the same framework. This algorithm is not stable yet and can change between Kotlin releases. As a workaround, you can rename the conflicting Kotlin classes in the framework.

(here)

[kpgalligan]

The statement above is accurate. You can’t control the name through annotations (or whatever). You would either need to rename the classes, mark them internal (if possible), or maybe have them in a separate module and export that through the module that creates the framework.

[ankushg]

It would be nice if there were warnings about name collisions for Kotlin Native artifacts though… sometimes I get worried that Foo and Foo_ will end up getting swapped around in a future compilation haha

[kpgalligan]

Oh, yeah, it would be great if there was more control

[Anders Oedlund]

@Neal Sanche would it work to enable generateAsInternal for the apollo gradle plugin, to not get the GraphQL classes exposed ?

[Neal Sanche]

Maybe, though we're much less worried about leaking the GraphQL classes, and more worried about the reason @ankushg mentioned above, that classes will get swapped. What we decided to do after giving this some thought was whenever we create a GraphQL Fragment, we name it BlahDTO. This avoids a name collision of the fragments at least. We will have to be careful not to name things the same elsewhere. And we've decided to not worry about making domain classes or copying GraphQL classes into domain classes. The Android or iOS apps can do that themselves. So for us, KMM becomes mostly a thin wrapper around operating with GraphQL. @Anders Oedlund I didn't know about generateAsInternal but right now that's off the table because we don't want to have to make domain classes for everything in GraphQL. We're mostly happy with what it's been generating for us.

[Neal Sanche]

But, it would be an excellent option to generate everything as internal, and just expose what we want. I'll experiment with it anyway and see what it does.