If I have `MyObject.Companion.foo()` in kotlin cod...

# kotlin-native

[russhwolf]

If I have MyObject.Companion.foo() in kotlin code compiling to a framework, what’s the proper way to access it from Swift? The only thing I can figure out how to do is MyObjectCompanion.init().foo(), but that doesn’t seem right because I don’t want to be creating a new instance of the companion object.

[svyatoslav.scherbina]

MyObjectCompanion().foo() is right. It actually doesn’t create a new instance, but returns the single instance every time.
I believe this way to expose Kotlin object declaration follows Swift and Objective-C conventions about singletons, isn’t it?

[russhwolf]

Yeah I guess I'm just not as used to the Swift/ObjC convention here. Thanks.

[Konstantin Petrukhnov]

does it return same instance in kotlin-native, or also in jvm?

[Konstantin Petrukhnov]

when calling MyObjectCompanion().foo()

[svyatoslav.scherbina]

@Konstantin Petrukhnov What do you mean? JVM is not involved when compiling Kotlin code to Objective-C framework.

[russhwolf]

@Konstantin Petrukhnov MyObjectCompanion().foo() is being called from Swift, not Kotlin. On JVM in Kotlin it would look like MyObject.foo() the same as always.

[drofwarcs]

@russhwolf I agree that doesn't feel right or look right. I would have expected Kotlin companion class to behave similiar to an objc/swift Type Function which would have the calling convention of MyObject.foo() . I understand why K/N needs to create two separate classes, but do not understand why the foo function is created as an instance method under MyObjectCompanion. I believe the solution proposed here https://github.com/JetBrains/kotlin-native/issues/1549 whould be a good secondary option to expose similar syntax.

[drofwarcs]

I also think it will be kind of weird to give a framework created in Kotlin to an iOS developer and tell them that MyObject instance methods can be called normally but if you need to call its static methods you need to call a different class, i.e. MyObjectCompanion

[russhwolf]

I’ll follow that issue. Thanks

[yusuf3000]

Jumping on this issue, what is the expected behaviour for a kotlin enum with a companion object. The enum companion object in objC doesn’t have the same functions as the normal enum. Is this expected?

[svyatoslav.scherbina]

@drofwarcs
Formally speaking, Kotlin doesn’t have static methods. Methods declared in companion object are instance methods of companion object class. The same behaviour can be observed when calling these methods from Java if using Kotlin/JVM.
So you are speaking about going beyond the formal Kotlin model to provide simpler API. It indeed makes sense, so we are considering simplifying access to object members, but it must be done carefully.

the solution proposed here https://github.com/JetBrains/kotlin-native/issues/1549 whould be a good secondary option to expose similar syntax.

Which solution do you mean?

[yusuf3000]

Ah this github issue is precisely what i mean!

[yusuf3000]

To give more context, I have a class Test in kotlin with 1 instance method method1() and a companion object with an init. I want to call the init method from Swift so I call TestCompanion(), but then I can not invoke method1 on this instance as this init returns TestCompanion rather than Test

[svyatoslav.scherbina]

@yusuf3000 Do you mean that you have init method declared in Kotlin companion object?
If so, then it must be available as TestCompanion().doInit() in Swift.

[drofwarcs]

@svyatoslav.scherbina the solution I'm referencing is the @ObjCStatic option. The reasoning for having this option is the exact same reason I believe @JVMStatic was created on the JVM side. Somewhere along the development of the Kotlin language, it was deemed useful to allow Java apps to call a Kotlin companion object as if it was a static method instead of always doing MyObject.Companion.foo(). I feel as more Kotlin iOS frameworks are created, the community may see a similar need for that platform.

[drofwarcs]

I feel Kotlin has always done a great job of hiding itself from the platform its being used on. You can give a jar created from Kotlin to a Java developer and its a good chance they will not know that they are calling is Kotlin code. Kotlin idioms do not spill over in Java and force you to use Kotlin's calling conventions.....which I think is a HUUUUGEEEE plus for Kotlin's interopt. K/N should also benefit from this type of interopt

[drofwarcs]

I would say that my two requests would be
1. A way to hide the "Companion" from the native calling code(Objc/swift/c++...etc)
2. A way to fake calling Kotlin companion members as if the were static methods....even if thats not whats really going on under the hood. Again...similarly to @JVMStatic

[svyatoslav.scherbina]

Yes, something similar to @JvmStatic is the solution that we are considering.