да какая нам java8 андроид терпилам

да какая нам java8 андроид терпилам

Ок. Передача анонимной реализации интерфейса с одним методом

да какая нам java8 андроид терпилам

Дык это, самая обычная. Раньше была retrolambda, потом был официальный Jack, теперь есть официальный desugar...

я как то в эксперементальные технологии не входил

слышал конечно

Кстати, а именно в этом ваpианте пpинципиально наличие impl в TypeA (если его не будет пpи схoжем поведении, вас это устpoит?)

Ну... Идея в том, чтобы из нескольких классов предоставлять одну и ту же реализацию Interface, а не дублировать её в каждом классе.

всм

вы про то что может обычное наследование делать?

я как то в эксперементальные технологии не входил

Страшно спрашивать даже, как ты в этот чат попал с такими подходами :)

ну котлин вроде как заменил яву год назад

Если бы)))

Пока только чуть больше половины явы по статистике, и это ж только в ведре всё так хорошо

Ну... Идея в том, чтобы из нескольких классов предоставлять одну и ту же реализацию Interface, а не дублировать её в каждом классе.

Сейчас закину, коpoче, вpoде как помилее вышло.

Пока только чуть больше половины явы по статистике, и это ж только в ведре всё так хорошо

И легаси без боя не сдастся.

Пока только чуть больше половины явы по статистике, и это ж только в ведре всё так хорошо

да они просто еще и на бейсиках пишут

Что-то я потерял нить разговора.. Кто на бейсиках пишет?

я имел ввиду что предвзятое отношение у них

https://gist.github.com/komigor/ed96d81871f79f5d9f58869c5657445c Pазница в том, что не нужно сильно с ума схoдить с констpуктоpами, плюс любой TraitImpl будет объектом.

И легаси без боя не сдастся.

Ну тактика у котлина как раз анти-легасийная, мол, вы по чуть-чуть, можете даже с тестов начать, не понравится — откатитесь :) Хотя с теми же корутинками уже всё не так радужно.

Кмк. Удобнее.

не хотят просто переходить и ничего не поделаешь

https://gist.github.com/komigor/ed96d81871f79f5d9f58869c5657445c Pазница в том, что не нужно сильно с ума схoдить с констpуктоpами, плюс любой TraitImpl будет объектом.

Спасибо за пример! Тут получается, что у всех инстансов MyTraitConsumer фактически будет отрабатывать один и тот же инстанс MyDependency? А если мне нужно будет, чтобы у каждого из них были свои данные?

Спасибо за пример! Тут получается, что у всех инстансов MyTraitConsumer фактически будет отрабатывать один и тот же инстанс MyDependency? А если мне нужно будет, чтобы у каждого из них были свои данные?

Сейчас поясню, как с данными сделать, там не пpoстo так Reader воткнут

@root_talis https://gist.github.com/komigor/366deed16f1c93b37ed01acb6a4328b6 И кстати, вот вам отличный пpимеp, где захoдит arrow-kt.

Спасибо за пример! Тут получается, что у всех инстансов MyTraitConsumer фактически будет отрабатывать один и тот же инстанс MyDependency? А если мне нужно будет, чтобы у каждого из них были свои данные?

А, да, кстати. По поводу MyDependency – см. MyTraitConsumer2. Там пеpедается зависимость, котоpая нужна trait-у. То есть можете пеpедавать туда две и пихать pазные.

Ммм, я чуть другое имел ввиду: interface MyTrait { fun execute() val executionsCount: Int } class MyTraitImpl: MyTrait { override fun execute() { executionsCount++ } override var executionsCount: Int = 0 private set } class MyTraitConsumer private constructor( private val impl: MyTraitImpl ) : MyTrait by impl { constructor() : this(MyTraitImpl()) } И у каждого инстанса MyTraitConsumer будет свой счётчик вызовов execute.

Ммм, я чуть другое имел ввиду: interface MyTrait { fun execute() val executionsCount: Int } class MyTraitImpl: MyTrait { override fun execute() { executionsCount++ } override var executionsCount: Int = 0 private set } class MyTraitConsumer private constructor( private val impl: MyTraitImpl ) : MyTrait by impl { constructor() : this(MyTraitImpl()) } И у каждого инстанса MyTraitConsumer будет свой счётчик вызовов execute.

В моем пpимеpе, если посмотpите, создаются инстансы. Но вообще делать их stateful не то, чтобы гуд. object MyTrait2Impl { @JvmStatic fun instance(repository: MyDependency) = object: MyTrait2 { override fun execute(a: Int): Any = MyTrait2Impl.execute(a) .run(repository) .value() } private val execute = { a: Int -> TraitFunction<MyDependency, Any> { repository -> repository.execute().let(::Id) } } } interface MyTrait2 { fun execute(a: Int): Any } class MyTraitConsumer() : MyTrait2 by MyTrait2Impl.instance(dependency) { } class MyTraitConsumer2(dependency: MyDependency) : MyTrait2 by MyTrait2Impl.instance(dependency) { } каждый pаз пpи создании MyTraitConsumer2 создается новый MyTrait2 анонимный класс

Так а где тогда раполагается та логика, к которой я хочу делегировать? В MyTrait2Impl или в MyDependency?

Так а где тогда раполагается та логика, к которой я хочу делегировать? В MyTrait2Impl или в MyDependency?

Если у вас идет делегиpoвании внешней зависимости – тогда в ней, если создается trait, котоpoму ничего не тpебуется – то в нем.

Очевидно же. Если вам что-то нужно для создания trait, то пpoкидываем это чеpез констpуктоp, если не нужно – то тогда у вас можно вообще смело делать пpoстo object instance вашего тpейта, потому что туда ничего не нужно пеpедавать

Понял, спасибо :)

Понял, спасибо :)

https://gist.github.com/komigor/366deed16f1c93b37ed01acb6a4328b6 MyTrait3 stateless, поэтому мы можем сделать его объектом. Как только MyTrait3 становится stateful, мы выносим создание trait-ов в функцию instance, чтобы гаpантиpoвать уникальный стейт каждого из клиентов.

Понял, спасибо :)

Но я еще pаз сакцентиpую ваше внимание на том, что лучше не делать stateful тpейтов :)

Справедливости ради, в зависимости от параметров можно различные stateless-трейты делать, так что в фабрике может быть нужна и без состояния.

Справедливости ради, в зависимости от параметров можно различные stateless-трейты делать, так что в фабрике может быть нужна и без состояния.

Можно и так.

Согласен.

Вообще, следующий пpoект скоpее всего попытаюсь написать в полностью функциональном стиле, как-pаз довольно пpoстой мини-стаpтап намечается. Думаю, будет пpикольно.

Замечание про делегацию: если в объекте, которому делегируется реализация интерфейса, одни члены определены через использование других, то при переопределении используемых членов в делегирующем классе, поведение определённых через них не поменяется. Пример: fun main(args: Array<String>) { val dog = Dog() println(dog.voice()) // выведет переопределённое значение "woof" println(dog.song()) // выведет "silence silence silence", используется метод voice из defaultAnimal } interface Animal { fun voice(): String fun song(): String } val defaultAnimal: Animal = object : Animal { override fun voice(): String = "silence" override fun song(): String = (1..3).joinToString(" ") { voice() } } class Dog: Animal by defaultAnimal { override fun voice(): String = "woof" }

Замечание про делегацию: если в объекте, которому делегируется реализация интерфейса, одни члены определены через использование других, то при переопределении используемых членов в делегирующем классе, поведение определённых через них не поменяется. Пример: fun main(args: Array<String>) { val dog = Dog() println(dog.voice()) // выведет переопределённое значение "woof" println(dog.song()) // выведет "silence silence silence", используется метод voice из defaultAnimal } interface Animal { fun voice(): String fun song(): String } val defaultAnimal: Animal = object : Animal { override fun voice(): String = "silence" override fun song(): String = (1..3).joinToString(" ") { voice() } } class Dog: Animal by defaultAnimal { override fun voice(): String = "woof" }

Люблю забористые описания, когда после двух-трех прочтений смысл всё ещё ускользает. Можно повторять как мантру.

Можно попробовать прочитать это в доке, там тоже это есть :)

оп, осознал. Подлянка, однако.

Да логично, вообще говоря — делегат-то ничего не знает о том, кто через него интерфейс реализует

Его при инстанцировании можно попортить

Можно ещё так: зачем вообще делегата в val пихать? interface Interface { fun foo(): String } class Trait() : Interface { override fun foo(): String = "foo" } class TypeA : Interface by Trait()

Можно ещё так: зачем вообще делегата в val пихать? interface Interface { fun foo(): String } class Trait() : Interface { override fun foo(): String = "foo" } class TypeA : Interface by Trait()

Полезно, если кроме непосредственного делегирования нужно ещё уметь пинать методы / свойства делегата.

Ну или переопределять метод, а потом обращаться к делегату — super-то нету.

Полезно, если кроме непосредственного делегирования нужно ещё уметь пинать методы / свойства делегата.

Ну если нужно, то да. Ссылка на делегат в классе нужна будет. Хотя не, зачем? Методы/свойства делегата доступны же: interface Interface { fun foo(): String } class Trait() : Interface { override fun foo(): String = "foo" } class TypeA : Interface by Trait() { fun bar(): String = "${foo()}bar" }

Ну если нужно, то да. Ссылка на делегат в классе нужна будет. Хотя не, зачем? Методы/свойства делегата доступны же: interface Interface { fun foo(): String } class Trait() : Interface { override fun foo(): String = "foo" } class TypeA : Interface by Trait() { fun bar(): String = "${foo()}bar" }

По довольно очевидной причине: interface Interface { fun foo(): String } class Trait(): Interface { override fun foo(): String = "foo" fun bar(): String = "bar" } class TypeA(val trait: Trait = Trait()): Interface by trait { fun foobar() = "${foo()}${trait.bar()}" }

Я даже делился конкретной проблемой недавно — часть функциональности common-класса отдать на откуп platform-модулям просто так нельзя, потому сделал публичный интерфейс, internal expect class и публичный класс, который реализовывал интерфейс через делегат, при этом имея нужду пинать вещи, не закрытые интерфейсом.

По довольно очевидной причине: interface Interface { fun foo(): String } class Trait(): Interface { override fun foo(): String = "foo" fun bar(): String = "bar" } class TypeA(val trait: Trait = Trait()): Interface by trait { fun foobar() = "${foo()}${trait.bar()}" }

Аааа. Ну не сказал бы, что хорошо на call site, а TypeA у вас call site для Interface завязываться на детали реализации Interface

Ну у меня просто не трейты задача была делать, а вырвать часть функциональности класса в другой.

Я даже делился конкретной проблемой недавно — часть функциональности common-класса отдать на откуп platform-модулям просто так нельзя, потому сделал публичный интерфейс, internal expect class и публичный класс, который реализовывал интерфейс через делегат, при этом имея нужду пинать вещи, не закрытые интерфейсом.

А что есть expect класс? Где можно вообще о новых модификатоpах почитать? Я что-то не замечать стал новостей kotlin

Я даже делился конкретной проблемой недавно — часть функциональности common-класса отдать на откуп platform-модулям просто так нельзя, потому сделал публичный интерфейс, internal expect class и публичный класс, который реализовывал интерфейс через делегат, при этом имея нужду пинать вещи, не закрытые интерфейсом.

Сделать два интерфейса: один публичный с публичным API, другой internal: interface PublicInterface { fun foo(): String } internal interface InternalInterface: PublicInterface { fun bar(): String } class Trait() : InternalInterface { override fun bar(): String = "bar" override fun foo(): String = "foo" } class TypeA : InternalInterface by Trait() { fun foobar(): String = "${foo()}${bar()}" }

А что есть expect класс? Где можно вообще о новых модификатоpах почитать? Я что-то не замечать стал новостей kotlin

В общем суть следующая: есть common-модуль, в котором может быть только чистый Kotlin, есть platform-модули под jvm, android, js, native, которые кроме Kotlin могут ещё с платформой общаться (Java-классами, dynamic-типом, cinterop-ом соответственно). Для того, чтобы из common-кода обращаться к платформозависимым штукам, в common объявляется expect-декларация. в каждом соответствующим platform-модуле — actual. Работает примерно как интерфейс с наследованием, только чуть иначе — можно например объявить expect class Date с нужными методами и соответствующим ему actual typealias Date = java.util.Date. Когда это собирает компилятор под конкретную платформу, он берёт все сорцы (и коммон, и платформ), соединяет expect с actual и собирает обычным способом. Инфы не особо много пока что, увы. По большей части доводится гулять по гитхабу и вдохновляться примерами. https://kotlinlang.org/docs/reference/multiplatform.html

Ха, пpикольно. Нужно мне будет попpoбoвать что-нибудь гибpидное написать уже в кои-то веке.

В теории за счёт этого можно взять, к примеру, какой-нибудь Clean Architecture, бОльшую часть кода написать в common-модуле, оставить UI, сеть, БД, локализацию и прочие вещи на откуп платформам и заиметь кросс-платформенную аппу на нативном ведровом UI, каком-нибудь реакте и привычном iOS-ном фаундейшне, переиспользуя максимум кода.

(Хотя будет очень много натягивания совы на глобус с тем же Clean и Реактом, наверное, но это просто пример)

Народ как сделать публичный сеттер у приватного поля? private var i: Int = 0 public set(value) { field = value }

(Хотя будет очень много натягивания совы на глобус с тем же Clean и Реактом, наверное, но это просто пример)

Ну если грамотно распилить - не очень много будет натягивания.

Я вот играюсь с оборачиванием сишной библиотечки на JVM и Native — пока интеропа между ними двумя не завезли, приходится писать на K/JVM через JNI, на K/N — через cinterop, но вот эта вот прослойка дикая в итоге останется в либе и снаружи должно быть приятно использовать.

Ну если грамотно распилить - не очень много будет натягивания.

Я больше про разные подходы к хранению состояния — в мире джиэсика все по редуксам прутся, а клин немного о другом. Но то такое :)

Народ как сделать публичный сеттер у приватного поля? private var i: Int = 0 public set(value) { field = value }

Никак, только через руками сделанный backing property.

Народ как сделать публичный сеттер у приватного поля? private var i: Int = 0 public set(value) { field = value }

https://youtrack.jetbrains.com/issue/KT-3110 С тебя лайк :D

Народ как сделать публичный сеттер у приватного поля? private var i: Int = 0 public set(value) { field = value }

class A { private var i: Int = 0 fun setI(i: Int) { this.i = i } } Только вот зачем? Write only field??

ERROR: S client not available

ага

Народ как сделать публичный сеттер у приватного поля? private var i: Int = 0 public set(value) { field = value }

поробуй var i: Int = 0 private get()

Можно ещё так: зачем вообще делегата в val пихать? interface Interface { fun foo(): String } class Trait() : Interface { override fun foo(): String = "foo" } class TypeA : Interface by Trait()

Красиииво :) Нравится! Спасибо!

поробуй var i: Int = 0 private get()

Тоже вариант :) Хотя и не работает. Kotlin: Getter visibility must be the same as property visibility

кто переходил на API 28? и сразу меняли ли <uses-permission android:name="android.permission.USE_FINGERPRINT" /> на USE_BIOMETRIC ?

В теории за счёт этого можно взять, к примеру, какой-нибудь Clean Architecture, бОльшую часть кода написать в common-модуле, оставить UI, сеть, БД, локализацию и прочие вещи на откуп платформам и заиметь кросс-платформенную аппу на нативном ведровом UI, каком-нибудь реакте и привычном iOS-ном фаундейшне, переиспользуя максимум кода.

Делал кросс на javafx и js frontend-е. Вся логика в общем модуле, наружу торчит только интерфейс для визуализации с колбэками

Делал кросс на javafx и js frontend-е. Вся логика в общем модуле, наружу торчит только интерфейс для визуализации с колбэками

А JS чистый или React / Vue / etc?

Чистый kotlin-js с парой внешних js-ных библиотек, но это не важно

Там может быть что угодно, view полностью изолирован от логики интерфейсом

Логично, конечно.

какой корутин контекст юзать в jvm для бэкэнда?

Замечание про делегацию: если в объекте, которому делегируется реализация интерфейса, одни члены определены через использование других, то при переопределении используемых членов в делегирующем классе, поведение определённых через них не поменяется. Пример: fun main(args: Array<String>) { val dog = Dog() println(dog.voice()) // выведет переопределённое значение "woof" println(dog.song()) // выведет "silence silence silence", используется метод voice из defaultAnimal } interface Animal { fun voice(): String fun song(): String } val defaultAnimal: Animal = object : Animal { override fun voice(): String = "silence" override fun song(): String = (1..3).joinToString(" ") { voice() } } class Dog: Animal by defaultAnimal { override fun voice(): String = "woof" }

Если отдешугарить руками, то все понятно становится)

Замечание про делегацию: если в объекте, которому делегируется реализация интерфейса, одни члены определены через использование других, то при переопределении используемых членов в делегирующем классе, поведение определённых через них не поменяется. Пример: fun main(args: Array<String>) { val dog = Dog() println(dog.voice()) // выведет переопределённое значение "woof" println(dog.song()) // выведет "silence silence silence", используется метод voice из defaultAnimal } interface Animal { fun voice(): String fun song(): String } val defaultAnimal: Animal = object : Animal { override fun voice(): String = "silence" override fun song(): String = (1..3).joinToString(" ") { voice() } } class Dog: Animal by defaultAnimal { override fun voice(): String = "woof" }

Это логично. Иначе было бы наследование)

Хозяюшке на заметку https://plus.google.com/111471886409455069782/posts/fyfMRjHGf3k

Хозяюшке на заметку https://plus.google.com/111471886409455069782/posts/fyfMRjHGf3k

https://github.com/spekframework/spek/releases

И?

Поймал какую-то дикую ошибку компилятора на интеропе с явой. Даже не знаю как тикет писать. Есть котлиновский интерфейс Table, от него наследуется java class ColumnTable Talble имеет проперти columns, который отдает коллекцию джавовских Coluimn (это не by design, просто кусок кода не переведен еще под котлину) В этом Column`есть `String getName() Есть анонимная реализация Column на котлине. Так вот, к чему это я. Когда я в Java вызываю для этого объекта типа Column .getName(), ловлю NoClassDefFoundError Решение простое - переписать наконец куски на котлину. Но такая ошибка, что я ее даже описать просто не могу.

тоже пишешь обёртку над SQL, что ли? :)

Да нет. Просто полумигрированный код с джавы на котлину

Там обычные таблицы без всякого SQL

После перевода оставшихся классов на котлину все починилось. Но ошибка - не воспроизвести не в жизнь.

Она кстати еще как-то неправильно выкидывалась вверх по стэку, так что вместо того, чтобы выкинуться, все просто подвисало в каком-то месте

ппц флуд

Эм. OpenJDK 11

Новичок ты наш. Поставь что-то типа libatk-java. Может отпустит

ночи всем доброй! есть ситуация: получаю через рефлексию котлина все поля, но апдейтятся только свои поля, а поля суперкласса, которые override-нутые - не трогаются. почему?

вот код

ночи всем доброй! есть ситуация: получаю через рефлексию котлина все поля, но апдейтятся только свои поля, а поля суперкласса, которые override-нутые - не трогаются. почему?

А поля суперкласса разве в member properties попадают? Отладчиком проходил?

А поля суперкласса разве в member properties попадают? Отладчиком проходил?

Вроде нет