LINUX.ORG.RU

История изменений

Исправление Legioner, (текущая версия) :

Я не думаю, что на JVM это можно реализовать, сохранив разумную совместимость с Java. Поэтому в Kotlin этого нет и не будет.

extension functions это вообще из другой оперы, не нужно их приплетать. Это просто сахарок, когда ты вместо f(x, y, z) пишешь x.f(y, z).

Я говорю именно про «заимплементить интерфейс для чужого типа».

Хотя наверное можно сделать что-то вроде

class LibraryClass { ... }
interface MyInterface { ... }
class LibraryClass$MyInterface$1 implements MyInterface {
    private final LibraryClass $this;
    static MyInterface wrap(LibraryClass c) {
        return new LibraryClass$MyInterface$1(c);
    }
    ...
}

LibraryClass c = ...;
MyInterface i = LibraryClass$MyInterface$1.wrap(c);

где всё, что с долларами, будет неявно генерироваться и подставляться. Правда будут нежданчики вроде c != i, но в Kotlin с SAM-типами уже что-то похожее есть.

Исправление Legioner, :

Я не думаю, что на JVM это можно реализовать, сохранив разумную совместимость с Java. Поэтому в Kotlin этого нет и не будет.

extension functions это вообще из другой оперы, не нужно их приплетать. Это просто сахарок, когда ты вместо f(x, y, z) пишешь x.f(y, z).

Я говорю именно про «заимплементить интерфейс для чужого типа».

Исходная версия Legioner, :

Я не думаю, что на JVM это можно реализовать, сохранив разумную совместимость с Java. Поэтому в Kotlin этого нет и не будет.

extension functions это вообще из другой оперы, не нужно их приплетать. Это просто сахарок, когда ты вместо f(x, y, z) пишешь x.f(y, z).