I’m not Dmitry Petrov 🙂

@aamit01: wrong Dmitry 🙂

sorry!

😞

np

Injecting via field is a bad smell

@dmnk_89: that’s arguable

I assume that the coverage tool you’re using has support for filtering, so you can configure it to exclude the (presumably) unused setter of the property from coverage

@artem_zin: I am curious about Your arguments why it's not

@dmnk_89: compare

class Presenter(private val authService: AuthService, private val dataService: DataService, private val ioScheduler: Scheduler, private val timeScheduler: Scheduler, private val etc: Etc) {

}

vs

class Presenter(private val graph: ObjectGraph) {

  @Inject
  lateinit var authService: AuthService

  @Inject
  lateinit var dataService: DataService

  @field:[Inject IoScheduler]
  lateinit var ioScheduler: Scheduler

  @field:[Inject TimeScheduler]
  lateinit var timeScheduler: Scheduler

  @Inject
  lateinit var etc: Etc

  init {
    graph.inject(this)
  }
}

Personally 2nd variant is more readable for me, also it looks better than invoking constructor with huge set of parameters both in real code and in tests

I mean, you could always write it like this...

class Presenter(
    private val authService: AuthService,
    private val dataService: DataService,
    private val ioScheduler: Scheduler,
    private val timeScheduler: Scheduler,
    private val etc: Etc) {

}

If we are talking spring boot it would be

class Presenter @Autowired constructor(
private val authService: AuthService, 
private val dataService: DataService, 
@Qualifier("ioScheduler") private val ioScheduler: Scheduler, 
@Qualifier("timeScheduler") private val timeScheduler: Scheduler, 
private val etc: Etc) {

}

Sure, but what about instantiation (in tests/life)? Anyway, it’s very offtopic for this channel

simple question, does kotlin have runtime-overhead? if so, how much?

I can't see any reason for Kotlin to have runtime overhead

It produces plain old Java bytecode

I wasn't sure thank you 🙂

Well, there is some. @yole did a presentation on Kotlin performance benchmarking a while ago; maybe he can provide a link.

Nothing really unexpected, though:

Null checks and default parameters have some minor overhead that starts to add up when there are many parameters.

and how does the top-level execution work? If I look at the bytecode of kotlinc-produced output that had top-level executed code it still contains a wrapper class is it a JVM restriction?

Yes, see https://kotlinlang.org/docs/reference/java-to-kotlin-interop.html#package-level-functions for more details

TL;DR: one additional class per source file with top-level declarations.

I see

how come default parameters have overhead? I thought the were same as in java having many overloaded functions?

my slides are here: http://www.slideshare.net/intelliyole/kotlin-bytecode-generation-and-runtime-performance

That'd be a bit too much (2^n) overloads by default. For a function

foo

with default parameters, kotlinc generates a synthetic

foo$default

method with additional "mask" parameter. See also: https://kotlinlang.org/docs/reference/java-to-kotlin-interop.html#overloads-generation

well I think that I shouldn't think of null-checks "having overhead" because I'm sure that if I would annotate every single variable in my java code

@NotNull

or

@Nullable

both will benchmark equally

I'm happy that kotlin does this for me

In plain Java you would have emulated missing "default parameters" feature exactly that way. So I believe there's no overhead there (comparing to Java)