kopper @w.on-t.work · 10/08/2026you could have something like kotlin context params but afaict they "infect" the call stack the same way async function coloring does and given the whole point is aesthethics at that point why not use regular DI instead 100
kopper @w.on-t.work · 10/08/2026like i cant see any real reason for monolithic "User Service" classes. theres no reason not to split every individual action into its own service at which point all you have are a bunch of classes with a single function because you can't DI easily otherwise 100
kopper @w.on-t.work · 10/08/2026and like all DI "services" end up building on top of a few basic resources like a database connection pool which, like, how many times do you even set those more than once. why not globals? 100