<https://stackoverflow.com/q/61791680/11377112> so...

# announcements

[Animesh Sahu]

https://stackoverflow.com/q/61791680/11377112 somebody know how should I approach this? How should you tackle situation where there is multiple interfaces decalre default parameters in their function decalration. I've also put a reproducible example corresponding to kotlin playground in there.

[Stefan Beyer]

I prefer the principle of composition over inheritance.

class CommunicatorImpl(
    // ...
    val broadcast: BroadcastChannel<Event<Any>>,
    val receiver: Channel<Event<Any>>
) : Communicator {
    // ...
}

then you do not need to think about those interface collisions. you just call myCommunicator.broadcast.cancel(...) and myCommunicator.receiver.cancel(...)

cancelling both at the same time would be done via a method

class CommunicatorImpl(
    // ...
) : Communicator {
    // ...
    fun cancel(cause: Throwable? = null) {
        // translate cause into CancellationException
        // cancel both channels here
    }
}

[Animesh Sahu]

@Stefan Beyer But how about other functions, which doesn't clash? Do i really need to write them manually?

[Stefan Beyer]

no, the other functions can also be called with myCommunicator.broadcast.otherFunction(). it is a bit more verbose to call these, but on the flipside, the caller knows in what context this call is executed.

[Animesh Sahu]

I mean like it can be done in this way but the whole point of delegation. It could be possible when the cancel's default variable were not defined in both the interfaces. Isn't some other ways possible to make compiler know that both are defined exactly the same because thats what it is in the interfaces, both have default null.

[Animesh Sahu]

Compiler is just unsure about that if one have default of null and another be some other thing then there might be problem, but if we could possibly tell it that we have null in both declaration then...

[Stefan Beyer]

those types of delegation usually lead to brittle design: what if someone calls some state altering methods that only change the state of the receiver, but the broadcast depends on that change too? then your state is broken.
usually this is solved by hiding the fact that there is a broadcast and a receiver under the hood, only exposing the Communicator interface and manually mapping all the methods.

if design does not matter and this is just from the technical aspect of the question: this is not possible to my knowledge. you would need type classes or similar concepts for this to work.

[Animesh Sahu]

It was intended to cancel both the channel when cancel is called. Ok would try something else.

[Animesh Sahu]

:)