Can I formulate ```fun Provider<out Task>.generateChecksums(destination: Directory? = null) { ...

# getting-started

[Vampire]

Can I formulate

fun Provider<out Task>.generateChecksums(destination: Directory? = null) {
    get().generateChecksums(destination)
}

fun Task.generateChecksums(destination: Directory? = null) {
}

fun FileSystemLocation.generateChecksums(destination: Directory? = null) {
}

somehow so that the first one can work for both Task or FileSystemLocation?
Just adding another method does not work of course as both would have the same type-erased form unless I call it differently.

[nkiesel]

Can you add an interface which both Task and FileSystem implement?

[Vampire]

No

[Vampire]

They are 3rd party classes

[Vampire]

Best I could come up with while still missing explicit union types is

fun Provider<out Any>.generateChecksums(destination: Directory? = null) {
    when (val value = get()) {
        is Task -> value.generateChecksums(destination)
        is FileSystemLocation -> value.generateChecksums(destination)
        else -> error("Unsupported Type")
    }
}

but that's bad of course due to the method being callable on all providers.
I hoped there is maybe some way using implicit union types.

[ephemient]

@JvmName("generateChecksumsTaskProvider")
public fun Provider<out Task>.generateChecksums()

@JvmName("generateChecksumsFileSystemLocationProvider")
public fun Provider<out FileSystemLocation>.generateChecksums()

will both appear as .generateChecksums() to Kotlin code

[Vampire]

Ah, nice, thanks. Will try that.

[ephemient]

come to think of it, TaskProvider<out Task> wouldn't have any JVM signature conflicts

[Vampire]

How would that help? Then I couldn't call it on Provider<out Task>. Besides that there are 5 more types to cover.

[ephemient]

do you really need an extension on Provider<out Task> when tasks.register() gives you a more specific subtype?

[Vampire]

Yes. And as I said, there are also 5 more types to cover. I just reduced it to two for the question.

[Vampire]

Works perfectly fine now with the JvmName trick, thanks again