CLOVIS
05/25/2020, 6:36 PMComparator
and similar behavior interfaces (which are called ‘Type classes'? Please correct me if I'm wrong).
It would also allow to implement a behavior in different ways, and choose which behavior is used when calling a function (with an explicit with
parameter), which makes dependency injection trivial (possibility to implement patterns such as DAO with some nice syntax sugar).raulraja
05/26/2020, 9:40 AMCLOVIS
05/26/2020, 10:54 AMCLOVIS
05/26/2020, 3:48 PMclass Thing(val a: String)
interface Order<T> {
operator fun compareTo(other: T): Int
}
fun test(o: Order<T>) = o.compareTo(o2)
extension class ThingOrder: Order<Thing> { ... }
val thing: Thing = Thing("thing")
val thingOrder: ThingOrder = ThingOrder()
val foo = thing + thingOrder
// You can call all functions from Thing on 'foo', and you can also call functions from 'ThingOrder'; basically it's a combination of both objects
test(foo) // This is legal, even though Thing doesn't implement Order, because this specific object has been combined with an Order implementation.
As I see it, this could remove the need for with
parameters, which would make it possible to use these kind of interfaces in the standard library without having to change function declarations
I guess someone must have already thought of doing something like that, especially with Unions coming with Meta, and I guess there was a reason why this wasn't added to the proposal... I'm curious to what it is.
(I'm not posting this on the proposal itself out of fear of polluting the discussion, since I'm far from understanding all subtility of it... Please tell me if this is not the correct place either)raulraja
05/26/2020, 4:35 PMraulraja
05/26/2020, 4:35 PMraulraja
05/26/2020, 4:36 PMraulraja
05/26/2020, 4:36 PMCLOVIS
05/26/2020, 9:44 PM