но спринг не умеет еще такого, поэтому all-open в любом случае будет в плагинах

У меня все так, я стабы вообще юзаю (осуждали как-то), народ вот что-то продолжает жаловаться.

делегация классов помогла?

- "моки пофиксили" - это можно сказать с большой натяжкой (через доп плагины) Тут народ переходит на mockito 2.0 (которые поддерживает моки на final), что бы тестить Котлин классы. - Холодная компиляция, явно не становится быстрее - Anotation processor все так же отваливается и глючит с разными библиотеками - Плагин, последнее время стал подвешивать идею и вроде ощутимо больше жрать ресурсов те я бы резюмировал что за год НЕ стало как-то супер лучше, вроде все также. Но за 1.1 и его фичи конечно спасибо ?

Компиляцию собираются ускорить в ближайших релизах. У меня крайне редко возникают проблемы с annotation processing (использую permission dispatcher), просто чищу проект пару раз в неделю и всё работает. Если есть конкретные баги — kotl.in/issue

делегация классов помогла?

Ты мне так и не ответил, на уточняющий вопрос. Это мне нужно для каждого интерфейса вручную заводить дополнительный класс-заглушка?

Ты мне так и не ответил, на уточняющий вопрос. Это мне нужно для каждого интерфейса вручную заводить дополнительный класс-заглушка?

мог пропустить, ну я вижу так

Компиляцию собираются ускорить в ближайших релизах. У меня крайне редко возникают проблемы с annotation processing (использую permission dispatcher), просто чищу проект пару раз в неделю и всё работает. Если есть конкретные баги — kotl.in/issue

У меня нет, я поступил радикально - не использую annotation processing вообще (соблюдаю заветы Егора ?)

Тут кстати говорят что она ломает инкрементную компиляцию в Android https://developer.android.com/studio/build/optimize-your-build.html#annotation_processors Как это с Kotlin работает, вообще не понятно (хотя у Kotlin свои проблемы с AP).

правильно говорят)

у меня PermissionDispatcher вроде не сломал)

Ты мне так и не ответил, на уточняющий вопрос. Это мне нужно для каждого интерфейса вручную заводить дополнительный класс-заглушка?

Ну вот что-то такое, если у тебя большие интерфейсы, а нужно застабить только один метод, может быть полезно fun main(args: Array<String>) { val stub = MyServiceStub(DefaultMyService()) stub.doWork() // stubDoWork } interface MyService { fun doWork() fun init() fun destroy() } class DefaultMyService : MyService { override fun init() = println("init") override fun doWork() = println("doWork") override fun destroy() = println("destroy") } class MyServiceStub(val myService: MyService): MyService by myService { override fun doWork() = println("stubDoWork") }

у меня PermissionDispatcher вроде не сломал)

Ну почему это ни сделать руками (риторический вопрос)? Программировать это же интересно ?

Ну почему это ни сделать руками (риторический вопрос)? Программировать это же интересно ?

Большинство кода, который я пишу — это скучно. И уж тем более runtime permissions :)

Ну вот что-то такое, если у тебя большие интерфейсы, а нужно застабить только один метод, может быть полезно fun main(args: Array<String>) { val stub = MyServiceStub(DefaultMyService()) stub.doWork() // stubDoWork } interface MyService { fun doWork() fun init() fun destroy() } class DefaultMyService : MyService { override fun init() = println("init") override fun doWork() = println("doWork") override fun destroy() = println("destroy") } class MyServiceStub(val myService: MyService): MyService by myService { override fun doWork() = println("stubDoWork") }

OK, это я понял. Слегка менее удобно, когда они НЕ большие, а их много (если жить по sol I d). Ну это наша Android тема, с заморочка про архитектура. (вот я постепенно и перехожу на функциональные типы (A) -> B - не нужно плодить интерфейсы, легко писать реализации)

ребят, а давно в Котлине new выпилили?

OK, это я понял. Слегка менее удобно, когда они НЕ большие, а их много (если жить по sol I d). Ну это наша Android тема, с заморочка про архитектура. (вот я постепенно и перехожу на функциональные типы (A) -> B - не нужно плодить интерфейсы, легко писать реализации)

Ты просто object : Type делаешь?

ребят, а давно в Котлине new выпилили?

Лет 5-6 назад ?

ребят, а давно в Котлине new выпилили?

а он в нем был когда-то?

Лет 5-6 назад ?

понял

Лет 5-6 назад ?

?

Хорошо сказано ?

Ты просто object : Type делаешь?

Нет, сейчас как ты делаю, но мне не кажется это идеалом (плодить эти MyServiceStub).

Нет, сейчас как ты делаю, но мне не кажется это идеалом (плодить эти MyServiceStub).

Я б сказал бы что лучше вообще пользоваться мокито

Я б сказал бы что лучше вообще пользоваться мокито

А разработчики Kotlin так не считают (тот же Жемеров об этом говорил). Кто знает, какой для них самый идиоматичный способ тестировать Kotlin код?

junit

А разработчики Kotlin так не считают (тот же Жемеров об этом говорил). Кто знает, какой для них самый идиоматичный способ тестировать Kotlin код?

Когда Жемеров был против мокито?

Dmitry Jemerov [JB] используйте тот, который вам нравится. мы сами используем просто junit

Dmitry Jemerov [JB] используйте тот, который вам нравится. мы сами используем просто junit

Так mockito и junit это перпендикулярные вещи

Когда Жемеров был против мокито?

Пару раз говорил в интервью/конференция, особенно когда его спрашивают "почему классы не открытые по умолчанию".

одно другого не отменяет

одно другого не отменяет

Он не против (наверное), просто говорил что они его не юзают и у них нет проблем с final. Короче надо глянуть сорцы Kotlin ?

Ну я его юзаю, и у меня нет проблем с final)

у них data driven тесты в сорсах, им там моки не нужны

Пару раз говорил в интервью/конференция, особенно когда его спрашивают "почему классы не открытые по умолчанию".

Классы не открыты по умолчанию - это от дядюшки Боба в Clean Code. Мокито это совершенно не мешает, если следовать другим заветам - зависимости в виде интерфейсов, а не конкретных реализаций. И вот эти интерфейсы и мокаешь. Для тех, кто не любит юзать интерфейсы, были придуманы разные PowerMock-и. Да и тот же Мокито уже давно умеет мокать финальные классы.

В мокита не так давно можно стало файнал мокать

Почему не так давно? Пол года прошло уже.

не только у дядушки боба про закрытые классы. в эффектив джаве тоже

можно ли такой метод на котлине без анчекед каста написать?

https://pastebin.com/hN3eNpyD

stubEntityClass.createInstance()

?

на refied дженерике?

как вариант, да

inline fun <reified K> create():K = K::class.createInstance() типа того

или так fun <T> makeStub(stubEntityClass: Class<T>): T = when (stubEntityClass) { UserRes::class -> UserRes() UserLoginReq::class -> UserLoginReq() UserInfoDto::class -> UserInfoDto() MenuItemHolder::class -> MenuItemHolder() else -> throw IllegalArgumentException("There is no stub for class") } as T

или так fun <T> makeStub(stubEntityClass: Class<T>): T = when (stubEntityClass) { UserRes::class -> UserRes() UserLoginReq::class -> UserLoginReq() UserInfoDto::class -> UserInfoDto() MenuItemHolder::class -> MenuItemHolder() else -> throw IllegalArgumentException("There is no stub for class") } as T

И здесь не будет uncheked cast?

конечно будет, но только в одном месте %-)

https://pastebin.com/kGFg6DA5

при сборке андроид проекта получаю в логах: Could not connect to kotlin daemon. Using fallback strategy.

как это пофиксить?

и еще вот это Could not perform non-incremental compilation with Kotlin compile daemon, non-incremental compilation in fallback mode will be performed

а котлин как-то генерит айдишник объекта? если нет, то как я могу создать автоинкрементирующийся айдишник?

а котлин как-то генерит айдишник объекта? если нет, то как я могу создать автоинкрементирующийся айдишник?

Айдишник какого объекта?

Айдишник какого объекта?

класса, который сам и написал

Сделай компанион обжект со счетчиком

И инкременть его когда надо

Ну это и в джаве можно

то есть в инициализаторе?

я не очень понимаю

а вы пишете на котлине на кэмл кейзе или снейк?

кэмл канеш

это ж не питон)

private companion object { private val counter = AtomicInteger() } val id: Int init { id = counter.incrementAndGet() } будет служить тебе верой и правдой до первого перезапуска приложения)

вынеси val в property

ERROR: S client not available

Нет, тогда можно будет лешко плодить пользователей с одинаковыми id.

Нет, тогда можно будет лешко плодить пользователей с одинаковыми id.

так

хорошо

что делать?

в питоне @property

что делать?

разместить это свойство в теле класса

хм

надо тогда геттер создать для него

в котлине точно есть что-то крутое для этого

надо тогда геттер создать для него

для него уже создан геттер, ёпта

в котлине точно есть что-то крутое для этого

да, можно просто не совершать никаких телодвижений

для него уже создан геттер, ёпта

ты к тому, что data class?

ты к тому, что data class?

Я к тому, что понятие свойства в Котлине уже включает в себя геттер.

бля

какой же ахуенный язык

?

val x: Int эквивалентно private int x; public int getX() { return x; }

я дико тащусь с генераторов секвенций

я дико тащусь с генераторов секвенций

Можно пример? Я так и не применил.

Можно пример? Я так и не применил.

https://github.com/kotlin-projects/kotlin-euler/blob/master/src/main/kotlin/euler/Problem_0012.kt#L10 ну вот на примере этих задачек

https://github.com/kotlin-projects/kotlin-euler/blob/master/src/main/kotlin/euler/Problem_0012.kt#L10 ну вот на примере этих задачек

как в руби прям

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

щас хоть начало показывать тип переменных, а то совсем недавно это было проблемой

val numbers: IntArray = intArrayOf(10, 20, 30, 40, 50)

так я делаю для интов

тебе прям примитивы нужны?

а как сделать также для моих Customer

listOf

listOf

а лист это случаем не свзный список?

ArrayList

val testArray: ArrayList<Customer> = ArrayList(10)