Add very basic documentation for interop with Swift/Objective-C #1482

SvyatoslavScherbina · 2018-04-10T14:42:18Z

No description provided.

SvyatoslavScherbina · 2018-04-10T14:42:59Z

To be merged after #1481, #1490 and #1512

olonho · 2018-04-11T06:32:20Z

OBJC_INTEROP.md

+
+Kotlin/Native provides bidirectional interoperability with Objective-C.
+Objective-C frameworks and libraries can be used in Kotlin code if
+properly attached to the build (system frameworks are attached by default).


"attached to" -> "integrated with", attachment assumes somewhat asymmetrical relation.

But why this relation should be described as being symmetrical?
I mean, when importing a library to Kotlin code through cinterop, we don't import Kotlin code to the library.

We may use replace "attach" by "include" or "import".

Imported or used is fine with me.

olonho · 2018-04-11T06:33:06Z

OBJC_INTEROP.md

+See e.g. "Interop libraries" in
+[Gradle plugin documentation](GRADLE_PLUGIN.md#building-artifacts).
+Swift library can be used in Kotlin code if its API is exported to Objective-C
+with `@objc`.


Maybe explicitly mention "Pure Swift modules are not yet supported"?

Instead of the last sentence or after it?

olonho · 2018-04-11T06:33:34Z

OBJC_INTEROP.md

+
+The table below shows how Kotlin concepts are mapped to Swift/Objective-C and vice versa.
+
+| Kotlin | Swift | Objective-C | Notes |


olonho · 2018-04-11T06:36:49Z

OBJC_INTEROP.md

+Names of Kotlin classes and interfaces are prefixed when imported to Swift/Objective-C.
+The prefix is derived from the framework name.
+
+### Top-level functions and properties


Unit conversion paragraph?

Yes, it makes sense. What do you think, should it be related to function types mapping or to Unit type mapping?

Maybe function types.

olonho · 2018-04-11T06:37:34Z

OBJC_INTEROP.md

+
+### Top-level functions and properties
+
+Top-level Kotlin functions and properties are accessible as members of a special class.


olonho · 2018-04-11T06:39:25Z

OBJC_INTEROP.md

+### Number
+
+`NSNumber` is not automatically translated to Kotlin primitive types
+when used as Swift/Objective-C parameter type or return value.


Maybe some rationale, or not yet implemented motivation?

olonho · 2018-04-11T06:40:24Z

OBJC_INTEROP.md

+
+### Mutable collections
+
+Every Kotlin `MutableSet` is `NSMutableSet`, however the opposite is not true.


Please mention explicitly that all other collections, such as Map and List are properly mapped.

Actually while writing these paragraphs I was considering them to be read just as notes to the table, after following the corresponding links.
Now I see that they look very silly when being read as self-contained descriptions. So I suppose some of the paragraphs should be expanded.

olonho · 2018-04-11T06:41:34Z

OBJC_INTEROP.md

+Kotlin classes and interfaces can be subclassed by Swift/Objective-C classes
+and protocols.
+Currently a class that adopts Kotlin protocol should inherit `NSObject`
+(either directly or indirectly). Note that all Kotlin classes do inherit `NSObject`.


What do you mean here?

All Kotlin classes are visible to Swift/Objective-C as inheriting NSObject, so it is OK to adopt Kotlin protocol by a subclass of a Kotlin class.

Probably say that somehow more clear.

olonho · 2018-04-11T06:42:34Z

OBJC_INTEROP.md

+Currently a class that adopts Kotlin protocol should inherit `NSObject`
+(either directly or indirectly). Note that all Kotlin classes do inherit `NSObject`.
+
+Swift/Objective-C classes can be subclassed with Kotlin `final` class.


Please mention, that non-final inheritance and complex object hierarchies are not yet supported.

SvyatoslavScherbina · 2018-04-11T07:14:28Z

OBJC_INTEROP.md

+# _Kotlin/Native_ interoperability with Swift/Objective-C
+
+This documents covers some details of Kotlin/Native interoperability with
+Swift/Objective-C.


Shouldn't we use some common name for Swift and Objective-C?

Good idea, although I've no idea what could it be.

r4zzz4k · 2018-04-13T16:10:31Z

OBJC_INTEROP.md

+| ------ | ----- |------------ | ----- |
+| `class` | `class` | `@interface` | [note](#name-translation) |
+| `interface` | `protocol` | `@protocol` | |
+| `constructor` | Initializer | Initializer | |


I'm not sure if constructors map to initializers in a natural way for Kotlin developers, so there probably should be some note on initBy(...) and invocation ordering.

Background:
I'm playing around with Kotlin/Native based iOS app and finding initializers a bit confusing (having no background in Obj-C / Swift).
I'm trying out code-only approach, so I've removed storyboards and invoking this in AppDelegate:

val mainViewController = ViewController() println("mainViewController ready [${mainViewController.hashCode()}]")

In my ViewController I've added logging to constructors and initWith... methods as following:

@ExportObjCClass class ViewController: UIViewController { init { println("ViewController [${hashCode()}] ctor: common init") } constructor(): super() { println("ViewController [${hashCode()}] ctor: no-arg") } constructor(aDecoder: NSCoder): super(aDecoder) { println("ViewController [${hashCode()}] ctor: NSCoder") } constructor(nibNameOrNil: String?, bundle: NSBundle?): super(nibNameOrNil, bundle) { println("ViewController [${hashCode()}] ctor: nibNameOrNil") } override fun init(): UIViewController? { println("ViewController [${hashCode()}]: init") return initBy(ViewController()) } override fun initWithCoder(aDecoder: NSCoder): UIViewController? { println("ViewController [${hashCode()}]: initWithCoder") return initBy(ViewController(aDecoder)) } override fun initWithNibName(nibNameOrNil: String?, bundle: NSBundle?): UIViewController { println("ViewController [${hashCode()}]: initWithNibName") return initBy(ViewController(nibNameOrNil, bundle)) } // ... }

Here's the resulting output:

ViewController [1807837959]: initWithNibName ViewController [1807837959] ctor: common init ViewController [1807837959] ctor: nibNameOrNil ViewController [1807837959] ctor: common init ViewController [1807837959] ctor: no-arg mainViewController ready [1807837959]

So there are several points I'm finding odd, which ask for being covered by interop documentation:

No-arg constructor leads to initWithNibName. This is probably due to init(nibName:bundle:) being designated initializer.

initWithNibName is being called before any constructor code. Looks like that's caused by the nature of initializers in Objective-C, so they are treated a bit differently from other methods. I see that initBy is intrinsic and has a special handling when invoked, but it's not documented in any way, so a note here might be helpful. And actual initWith... methods appear as usual methods in generated .kt stubs, so nothing reveals their real nature.

Two different constructors being called on one object, with two calls to init { ... } block. I guess Objective-C base class is able to invoke another constructor of derived class, and I'm not sure if such behavior can be achieved with Kotlin/JVM, so this also is a surprise point.

Please let me know if I'm doing something wrong or if something should be filled as an issue -- I'll try to provide as much details as possible.

@r4zzz4k overriding of initializers is tricky and considered to be redesigned.
The problem with your example is that you call super-constructor that is based on non-designated initializer. The compiler should prohibit this, however it doesn't.

I see, so this is temporary state of thins. And so even if I want to use no-arg constructor without working with nibs it should still invoke super(null, null) to reference UIViewController(nibNameOrNil: String?, bundle: NSBundle?). Is that correct? If so, something like this should be great to have for newcomers like me not to fail this trap:

Note: When implementing constructors of Kotlin classes which are extending Objective-C ones make sure you are calling superclass constructor corresponding to it's designated initializer (i.e. initWithNibName:bundle: for UIViewController).

if I want to use no-arg constructor without working with nibs it should still invoke super(null, null) to reference UIViewController(nibNameOrNil: String?, bundle: NSBundle?).

Yes. Swift also has this requirement.

We will either add such a warning to this doc or forbid this case in the compiler.

Maybe some high level description of initBy and current state of things around initializers makes sense indeed.

@olonho btw, I'm working on some improvements to Objective-C initializers support, which would make initBy (and also calling/overriding init* methods) obsolete. So I suggest waiting until this work is done and then completing the documentation about initializers.

And here it is: #1512

olonho · 2018-04-17T09:53:40Z

OBJC_INTEROP.md

+```
+foo {
+    bar($0 as! Int32)
+    return KotlinUnit()


Not too pretty, but we could live with it.

olonho · 2018-04-17T10:05:03Z

OBJC_INTEROP.md

+and protocols.
+Currently a class that adopts Kotlin protocol should inherit `NSObject`
+(either directly or indirectly). Note that all Kotlin classes do inherit `NSObject`,
+so a subclass of Kotlin class can adopt Kotlin protocol.


Not entirely clear to me. Maybe "subclass of Kotlin class" -> "Objective-C subclass of Kotlin class"?

It makes sense.

Add very basic documentation for interop with Swift/Objective-C

a2b165d

olonho reviewed Apr 11, 2018

View reviewed changes

SvyatoslavScherbina commented Apr 11, 2018

View reviewed changes

Update OBJC_INTEROP.md

062e5dd

r4zzz4k reviewed Apr 13, 2018

View reviewed changes

olonho reviewed Apr 17, 2018

View reviewed changes

OBJC_INTEROP.md

```

foo {

bar($0 as! Int32)

return KotlinUnit()

Copy link

Contributor

olonho Apr 17, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not too pretty, but we could live with it.

olonho reviewed Apr 17, 2018

View reviewed changes

olonho approved these changes Apr 18, 2018

View reviewed changes

Update OBJC_INTEROP.md

5efcfe7

olonho approved these changes Apr 18, 2018

View reviewed changes

Update OBJC_INTEROP.md

840f22e

SvyatoslavScherbina merged commit f27d445 into master Apr 18, 2018

SvyatoslavScherbina deleted the objc-interop-docs branch April 18, 2018 17:46

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add very basic documentation for interop with Swift/Objective-C #1482

Add very basic documentation for interop with Swift/Objective-C #1482

SvyatoslavScherbina commented Apr 10, 2018

SvyatoslavScherbina commented Apr 10, 2018 •

edited

Loading

olonho Apr 11, 2018

SvyatoslavScherbina Apr 11, 2018

olonho Apr 17, 2018

olonho Apr 11, 2018

SvyatoslavScherbina Apr 11, 2018

olonho Apr 11, 2018

olonho Apr 11, 2018

olonho Apr 11, 2018 •

edited

Loading

SvyatoslavScherbina Apr 11, 2018

olonho Apr 11, 2018

olonho Apr 11, 2018

olonho Apr 11, 2018

olonho Apr 11, 2018

SvyatoslavScherbina Apr 11, 2018

olonho Apr 11, 2018

SvyatoslavScherbina Apr 11, 2018

olonho Apr 11, 2018

olonho Apr 11, 2018

SvyatoslavScherbina Apr 11, 2018

olonho Apr 11, 2018

r4zzz4k Apr 13, 2018

SvyatoslavScherbina Apr 16, 2018

r4zzz4k Apr 16, 2018

SvyatoslavScherbina Apr 16, 2018

olonho Apr 17, 2018 •

edited

Loading

SvyatoslavScherbina Apr 17, 2018

SvyatoslavScherbina Apr 18, 2018

olonho Apr 17, 2018

olonho Apr 17, 2018

SvyatoslavScherbina Apr 17, 2018


		The table below shows how Kotlin concepts are mapped to Swift/Objective-C and vice versa.

		\| Kotlin \| Swift \| Objective-C \| Notes \|


		### Top-level functions and properties

		Top-level Kotlin functions and properties are accessible as members of a special class.


		### Mutable collections

		Every Kotlin `MutableSet` is `NSMutableSet`, however the opposite is not true.

Add very basic documentation for interop with Swift/Objective-C #1482

Add very basic documentation for interop with Swift/Objective-C #1482

Conversation

SvyatoslavScherbina commented Apr 10, 2018

SvyatoslavScherbina commented Apr 10, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

olonho Apr 11, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

olonho Apr 17, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SvyatoslavScherbina commented Apr 10, 2018 •

edited

Loading

olonho Apr 11, 2018 •

edited

Loading

olonho Apr 17, 2018 •

edited

Loading