is there a trick to overcome clashing function sig...

# getting-started

[elect]

is there a trick to overcome clashing function signatures with different returns values?

fun TfFile.cert_request(configure: CertRequest.() -> Unit): CertRequest

fun TfFile.cert_request(configure: CertRequest.() -> Unit): PropertyDelegateProvider<Any?, ReadOnlyProperty<Any?, CertRequest>>

@JvmName works only for case like List<String and List<Int and @OverloadResolutionByLambdaReturnType only with lambdas returning different values

[Joffrey]

Compiler problems aside, how would you expect people to understand which function is called?

[elect]

cert_request { }
            val a by cert_request { }

if I make use of delegation or not

[Joffrey]

In the case where you don't use it with by, how do you know which one it is?

[elect]

ok

[Youssef Shoaib [MOD]]

How about implementing an operator fun CertRequest.provideDelegate
? Could that do the trick?

[elect]

I played with the provideDelegate, but I didn't have any luck 😕

[Youssef Shoaib [MOD]]

Is there a specific reason why it didn't work? Whenever a property is delegated to a CertRequest the `provideDelegate`method should be called automatically, allowing you to do whatever you want. In fact, you can take the current method which returns a Delegate provider and instead make it return its delegate in CertRequest.provideDelegate

[Youssef Shoaib [MOD]]

You might need to make TfFile a context receiver I guess, but it should work I believe.

[elect]

ok, let's give it a try, why CertRequest.provideDelegate? I need as owner TfFile (I have to add this CertRequest instance to a list inside TfFile)

[Youssef Shoaib [MOD]]

Well, is there different logic between a normal CertRequest and one that's inside a property delegate?

[elect]

no

[Youssef Shoaib [MOD]]

If there is a difference, then you need this:

context(TfFile)
operator fun CertRequest.provideDelegate(...): ReadOnlyProperty<...> {
    [e-mail](this)
    [e-mail](generateNewCert())
    return ReadOnlyProperty<...> {...}
}

[Youssef Shoaib [MOD]]

Okay then, you don't even need a provide delegate. You can simply have this:

operator fun CertRequest.getValue(...): CertRequest = this

In other words, CertRequest is used as a delegate that just returns itself!
That then allows you to have only one TfFile.cert_request and still have it be used as a delegate when needed

[elect]

I'd like to use the variable name though
val a by cert_request , in this case a and save it inside CertRequest

[elect]

thta's why I was using provideDelegate pattern

[Youssef Shoaib [MOD]]

Is CertRequest modifiable after creation? If so:

operator fun CertRequest.provideDelegate(...): CertRequest= this.apply {
    this.myName = property.name
}
operator fun CertRequest.getValue(...): CertRequest = this

[elect]

I can make it modifiable

[Youssef Shoaib [MOD]]

If you wanna keep it not modifiable though, it is a bit more awkward but you can do something like this:

context(TfFile)
operator fun CertRequest.provideDelegate(...): CertRequest = this.copy(name = property.name).also {
    [e-mail](this)
    [e-mail](it)
} 
operator fun CertRequest.getValue(...): CertRequest = this

But yes I'd suggest to just make it modifiable to make it easier

[elect]

so, I have the following, how the by cert_request is supposed to call CertRequest.provideDelegate? Because it's always being redirected to TfFile.cert_request

[elect]

did you mean val a by CertRequest()?
It works quite good in this way indeed

[Youssef Shoaib [MOD]]

No I meant exactly what is in the gist. Does it not work as expected?

[elect]

wait

[elect]

no you are right, it works, now I get what you meant: so first TfFile.cert_request is called, and then CertRequest.provideDelegate

[elect]

that's a sweet trick, thanks Youssef metal

[Youssef Shoaib [MOD]]

Yep exactly! No problem at all, glad I could help!