I m curious as to the thinking behind the structuring of fea

Question

I m curious as to the thinking behind the structuring of features

Jonathan Mew · Answer

In particular I ve just made a new version of the CallLogging feature and ended up getting a bit confused and picking it apart

Jonathan Mew · Answer

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

Jonathan Mew · Answer

Would there be any sense in giving these things separate names rather than both feature

Jonathan Mew · Answer

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

Jonathan Mew · Answer

but maybe it s more idiomatic for Kotlin I m not sure

Jonathan Mew · Answer

Not causing me any problems just curious slightly smiling face

ribesg · Answer

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

Jonathan Mew · Answer

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

Jonathan Mew · Answer

confirmed ``` fun configure with application install CallLogging mdc blah call gt blah install CallLogging mdc boo call gt boo ``` ``` frontend log collector | Caused by io ktor application DuplicateApplicationFeatureException Conflicting application feature is already installed with the same key as `Call Logging```

Jonathan Mew · Answer

or perhaps I have the wrong end of the stick

ribesg · Answer

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

Jonathan Mew · Answer

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

Jonathan Mew · Answer

thanks < ribesg> for your thoughts anyway slightly smiling face