https://kotlinlang.org logo
#ktor
Title
# ktor
j

Jonathan Mew

05/13/2019, 3:43 PM
I'm curious as to the thinking behind the structuring of features
In particular I've just made a new version of the CallLogging feature and ended up getting a bit confused and picking it apart.
In the calling install code, there seem to be two notions called 'feature' - some object used at configuration time to set things up and an instance object that might hang around and sort of cache the configuration for later reference.
Would there be any sense in giving these things separate names rather than both 'feature'?
Also is there a benefit to using a companion object rather than just a top-level object? IMO it makes the code harder to read.
but maybe it's more idiomatic for Kotlin, I'm not sure...
Not causing me any problems, just curious 🙂
r

ribesg

05/13/2019, 8:27 PM
You could have multiple instances of one feature. The companion hosts the installation code, which is the same for all instances, then any instance can contain different configuration and data and act differently based on that
j

Jonathan Mew

05/14/2019, 7:08 AM
I thought that, but the key is hard coded on the companion object and I believe having two instances will cause a failure. You'd need a different key for each instance.
confirmed:
Copy code
fun configure() {
        with(application) {
            install(CallLogging) {
                mdc("blah", {call -> "blah"})
            }
            install(CallLogging) {
                mdc("boo", {call -> "boo"})
            }
...
}
Copy code
frontend-log-collector    | Caused by: io.ktor.application.DuplicateApplicationFeatureException: Conflicting application feature is already installed with the same key as `Call Logging
or perhaps I have the wrong end of the stick...
r

ribesg

05/14/2019, 7:52 AM
You’re right. Not sure why it is how it is then. It didn’t cause me any problem, but maybe it’s a bit weird
j

Jonathan Mew

05/14/2019, 7:56 AM
Yeah, I started out following the pattern because that felt easiest but a colleague (rightly IMO) pointed out that it would be easier to read unpacked. As before though, maybe it's idiomatic to Kotlin. But I do really think having distinct names for a cached configuration vs a thing that configures the application at install time would be an improvement!
thanks @ribesg for your thoughts anyway 🙂
3 Views