[WIP] Kotlin support

[levi]

Very much WIP. Currently builds off the other Swift PR.

Still determining a design strategy for the models, likely will use a hybrid of data classes and the builder pattern. Open to suggestions.

[ghost]

🚫 CI failed with log

[ghost]

	3 Warnings
⚠️	PR is classed as Work in Progress
⚠️	This is a big PR, please consider splitting it up to ease code review.
⚠️	Any source code changes should have an entry in CHANGELOG.md or have #trivial in their title.

Generated by 🚫 Danger

[ghost]

🚫 CI failed with log

[rahul-malik]

@levi sounds great. I imagined we would generate data classes and as far as builders this approach seemed interesting

http://kotlinlang.org/docs/reference/type-safe-builders.html

[maicki]

Would this support conversion between Map / JSON <-> Model out of the box like Codable on the Swift side?

[levi]

@maicki as far as I undertand, Kotlin doesn't currently have a codable-like feature. I was planning on taking the coder agnostic approach that we already do with the Obj-c implementation.

[rahul-malik]

@levi let me know how i can help move this one along as there are more unknowns than the Swift implementation. I can bring in some Kotlin folks at Pinterest to review the proposed generated code / patterns

[rahul-malik]

Foundation? In Kotlin?

[christinalee]

Levi let me know if you want to strategize Kotlin implementation. Would be happy to help, as I have an interest in having Kotlin supported as well :)

[maicki]

Would be good to know what is are the missing pieces to get it over the finish line cc @levi. If we could get Kotlin support into Plank, so we test it within Pinterest that would be huge.

[levi]

@christinalee would appreciate some insight on a builder pattern API you'd find useful. The rest of the work is pretty straight forward to implement.

[rahul-malik]

@levi @christinalee - Thoughts on this approach: https://proandroiddev.com/dsl-builder-in-kotlin-be5816ba3ca7

[christinalee]

@rahul-malik given the presence of named constructor variables, default copy implementations in data classs, and the ability to use lambdas with receivers like apply I'm not sure the DSL is necessary here. Need a bit more insight into Plank's structure before making a Builder pattern suggestion though, so will sync with you offline and then get back to @levi

[maicki]

Should we start an issue like the one we did with flow: #56 were we maybe figure out together the right API / patterns we will use?

[christinalee]

Would be happy to @maicki. Rahul Bkase and I also spent a few hours discussing this. We went down several different paths but ended up looping back to the traditional static-esque builder pattern, that has a data class with a companion object that handles the building like this example:

    companion object {
        private const val UNINITIALIZED_STR = "" // for example purposes only

        class Builder {
            private var uid: String = UNINITIALIZED_STR
            private var imgUrl: URL = URL(UNINITIALIZED_STR)

            fun uid(uid: String): Builder {
                this.uid = uid
                return this
            }
            
            fun url(imgUrl: URL): Builder {
                this.imgUrl = imgUrl
                return this
            }
            
            fun build(): Pin {
                return Pin(uid, imgUrl)
            }
        }
    }
} 

We discussed numerous other options (including the one linked above), but when considering method counts, performance, and java interoperability, this seemed to give us the most utility with the fewest sacrifices. Because the object is a data class, Kotlin callers can use the built in copy to create new pins with certain fields changed while Java callers can route through the explicit builder pattern (they also, of course, have access to the copy method but since Java doesn't support default parameters it's a glorified constructor from Java call sites and therefore isn't super useful). Callers from both languages benefit from the built in hashCode and equals generation on the data class.

Anywho, happy to hear feedback and continue iterating on this idea, but based on our explorations, wanted to throw this out as a starting suggestion