How about default class implementations for interf...

# language-proposals

[Ben Woodworth]

How about default class implementations for interfaces? Especially when it comes to composition/delegation, this is a common pattern I see:

interface SomeTrait { ... }

private class SomeTraitImpl(...) : SomeTrait { ... }

fun SomeTrait(...): SomeTrait = SomeTraitImpl(...)

And used like this:

class MyClass : SomeTrait by SomeTrait(...)

// Or just used to get an instance of the default implementation:
val trait = SomeTrait(...)

What if a default implementation could be given, something like this:

interface SomeTrait {
    ...

    default class(...) { // Optional name, like companion objects. Implicitly implements SomeTrait.
        ...
    }
}

// No need for a pseudo-constructor function:
val trait = SomeTrait(...) // gets an instance of the default class

Maybe treat "extending" this interface as delegation to the default implementation:

class MyClass : SomeTrait(...)

// Desugars to:
class MyClass : SomeTrait by SomeTrait(...)

It'd probably just be unnecessary added complexity to the language, but it seems like it has potential to simplify some things, it avoids the whole *Impl naming controversy, and it's definitely fun to consider :)

[Hanno]

When there is nothing to implement, the class can be skipped and object: SomeTrait{} can be used everywhere SomeTraitImpl would be used. The only thing Missing then is that instantiation syntax is slightly different, compared to a pseudo constructor. Isnt that sufficient or am i missing sth?

[Ben Woodworth]

The implementation might have state, so a single instance won't always cut it

[Ben Woodworth]

After thinking about it more, I'd probably just use an anonymous object:

fun SomeTrait(...): SomeTrait = object : SomeTrait {
    ...
}

[alexsullivan114]

My gut reaction is that if this pattern is needed that often it might mean it's time to stop using so many interfaces that have only one actual implementation.

[Hanno]

@Ben Woodworth thats actually what i meant.

[Ben Woodworth]

@alexsullivan114 It's a way to get around multiple inheritance. If multiple inheritance were possible I'd just use open/abstract classes. Here's an article I found that uses a similar approach:
https://avwie.github.io/compositional-patterns-in-kotlin-part-1-delegation

@Hanno For some reason I thought you meant a non-anonymous object. My bad 😅

[Hullaballoonatic]

yeah, you can basically do multiple inheritance by delegation, and syntactic sugar or default implementations would essentially mean that the language endorses multiple inheritance. i'm not sure that's a direction jb wants to take it, but i'm in support.

[mcpiroman]

I'm totally after, but I'd take the other way around: define automatic interface for a class, not class for interface. That way you could do class Base1; class Base2; and then class Derived : Base1(), Base2 by Base2()
And then maybe class Derived : Base1(), Base2() as syntax sugar for above?

[mcpiroman]

Actually, there is a related proposal here: https://youtrack.jetbrains.com/issue/KT-5751

[Hullaballoonatic]

I don't understand what you mean by automatic interface for a class. classes can extend interfaces, and all subclasses implement the same interface.