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

Marc Knaup

03/13/2020, 10:50 AM
It would be even more awesome if all those classes would be interfaces, so that you can create a new interface that implements them by delegation. That would allow bringing many extensions in scope!
I guess that may not work that well due to excessive use of extension functions and nested DSL though 😕
c

cy

03/13/2020, 10:53 AM
Well, from the classes, the only that don't have interface is Route. I see no reason to delegate it
Could you please explain your usecase?
m

Marc Knaup

03/13/2020, 10:56 AM
My DSL allows adding handlers to an existing route by accepting a
Route.() -> Unit
lambda. I could use my own interface for defining handlers that take
MyRoute.() -> Unit
instead.
MyRoute
has contextual properties and special contextual DSL.
Same for
Application
and
PipelineContext
(handlers). I get some local state from the respective
attributes
and make it available through a nice DSL.
c

cy

03/13/2020, 10:57 AM
These are interface and function
(function is almost interface)
Route is open so you may create your own implementations
m

Marc Knaup

03/13/2020, 10:59 AM
I have to use
Application
for example because plenty of 1st and 3rd party modules add extension functions to it. So I cannot use my own implementation and simply funnel everything to the
Application
behind the scenes. I would have to replicate all extension functions of all possible Ktor features/libraries.
Basically what I’m building is another layer on top of Ktor that wires together modular configuration with Kodein + [Ktor] + [MongoDB] + [GraphQL]. So I have one DSL over everything and specific integrations for each “module” like Ktor. Making them work nicely together isn’t the easiest task :)