Как правильно подсказывают есть саппорт либа, а еще есть MockK

спасибо ?

знаю, но там как-то мертво все

Там ветка 2.0 развивается вроде

А вот пример отличий junit 5.0 - 5.1 с точки зрения котлина https://github.com/Heapy/yml-ical/commit/5c559932947ba2c1fa2fd2d7ca647eb6bf8f941f

Там ветка 2.0 развивается вроде

тоже не особо активно

По мне эта матрешка - ФП, заменить классы на функции со счетчиками и будет ФП

интересное заявление

слушал доклад где поясняли почему самый правильный ооп это clojure

https://github.com/oleksiyp/mockk

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

слушал доклад где поясняли почему самый правильный ооп это clojure

если не сложно, можно ссылку?

интересно было бы послушать

если не сложно, можно ссылку?

youtube fpconf 2017

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

allopen плагин https://kotlinlang.org/docs/reference/compiler-plugins.html

если не найдете за 20 минут - кину, пока читаю историю всех чатьв

Там ветка 2.0 развивается вроде

ну 21го 6 коммитов, вполне нормальное развитие для более-менее готовой либы

ну 21го 6 коммитов, вполне нормальное развитие для более-менее готовой либы

4 коммита и это спустя месяц

и до "более-менее" готовой там довольно далеко

allopen плагин https://kotlinlang.org/docs/reference/compiler-plugins.html

да, он, спасибо, а в мокито его не завезли? или никто просто не занимался?

да, он, спасибо, а в мокито его не завезли? или никто просто не занимался?

Это ортогональные вещи, allopen смотрит на аннотации и делает классы открытыми (например для спринговых @Service, etc). Можно использовать свои аннотации, например написать аннотацию @Testable. Но я просто делаю интерфейсы когда мне нужно мокать.

Это ортогональные вещи, allopen смотрит на аннотации и делает классы открытыми (например для спринговых @Service, etc). Можно использовать свои аннотации, например написать аннотацию @Testable. Но я просто делаю интерфейсы когда мне нужно мокать.

четно говоря я грущу когда нужно делать интерфейсы без реальной необходимости в этом. Уж очень не нравится MyInterface и MyInterfaceImpl

Я делаю Interface и DefaultInterface

youtube fpconf 2017

https://www.youtube.com/playlist?list=PLY3spNmwoSY-4hso5zlqzv7IkYlscw6jw чёт тут по clojure не грепается

Я делаю Interface и DefaultInterface

Вот пример как это смотрится https://github.com/Heapy/yml-ical/blob/master/src/main/kotlin/by/heap/calendar/yml/FileWriter.kt#L13

https://www.youtube.com/playlist?list=PLY3spNmwoSY-4hso5zlqzv7IkYlscw6jw чёт тут по clojure не грепается

https://youtu.be/b-Eq4YV4uwc

вот эта, но там по чуть чуть набрасывают на вентилятор

https://youtu.be/b-Eq4YV4uwc

точно, как я не догадался что Рыжиков как всегда за кложу топит

Вот пример как это смотрится https://github.com/Heapy/yml-ical/blob/master/src/main/kotlin/by/heap/calendar/yml/FileWriter.kt#L13

та ну всё-равно как-то... кстати, а почему тогда не префикс I

Шарпы какие-то получаются с этим вот I)

та ну всё-равно как-то... кстати, а почему тогда не префикс I

Ну как показала практика это самое логичное именование, бывали случаи когда реально появлялась альтернативная имплементация и вот она называлась например AmazonInterface. Ну и получалось что есть Interface, DefaultInterface и AmazonInterface. Намного понятнее красивее чем Impl имхо

Вот пример как это смотрится https://github.com/Heapy/yml-ical/blob/master/src/main/kotlin/by/heap/calendar/yml/FileWriter.kt#L13

Спасибо, симпатичный подход)

Ну как показала практика это самое логичное именование, бывали случаи когда реально появлялась альтернативная имплементация и вот она называлась например AmazonInterface. Ну и получалось что есть Interface, DefaultInterface и AmazonInterface. Намного понятнее красивее чем Impl имхо

ну про слово Default - окей, тут по большей части фломастеры, но вот в целом идея делать интерфейсы только для того чтобы суметь замокать - это как-то странно. Если нужна будет альтернативная имплементация - окей, проводим рефакторинг выделение интерфейса и делаем новую имплементацию, но тогда понятно откуда взялся интерфейс и зачем он вообще. единственный вариант я нашёл зачем может понадобиться интерфейс при единственной имплементации - это сокрыть остальные методы не нужные для большинства пользователей, чтобы было понятнее как предполагается использовать класс, ну и чтобы никто ничего лишнего лишний раз не вызывал

Grushin Sergey Work: народ, в процессе реализации была задача. пройти коллекцию элементов и поменять один булин у одного элемента этой коллекции + получить индекс. я реализовал так data.indexOfFirst { it.isNotesExpand }.let { if (it != -1) { data[it].isNotesExpand = false notifyItemChanged(it + 1) } }

можно ли его сократить?)

вот эта, но там по чуть чуть набрасывают на вентилятор

Наверное ты все таки имел ввиду доклад “Сергей Ткаченко. OOP FOR BRAVE AND TRUE” Николай в своем докладе ничего про ООП не говорит.

Наверное ты все таки имел ввиду доклад “Сергей Ткаченко. OOP FOR BRAVE AND TRUE” Николай в своем докладе ничего про ООП не говорит.

точно говорил, я же его в живую слушал, пара набросов была, что раз есть объекты и сообщения то чем вызов метода нн сообщение

Ребят, можно как-то сахарно проверить массив на какое-то условие? Например массив стрингов на то, что все строки в нем начинаются с символа а

Ребят, можно как-то сахарно проверить массив на какое-то условие? Например массив стрингов на то, что все строки в нем начинаются с символа а

matchAll нет?

По памяти

matchAll нет?

Возможно, сейчас нет возможности проверить, но посмотрю, спасибо.

Ребят, можно как-то сахарно проверить массив на какое-то условие? Например массив стрингов на то, что все строки в нем начинаются с символа а

.all {}

.all {}

Точно, спасибо:)

Ребят, кто что скажет по поводу такого кодстайла (пример так, либо с проверкой на что-либо ещё), когда первая часть условия — на одной строке с сигнатурой (без переноса, телеграм сам перенёс, конец сигнатуры на else {): fun someFunction(param: Int) = if (param != 42) someFunction(param+1) else { // other code } Ну и аналогичное с when: насколько с этим неудобно работать/неудобно читать остальным?

Ребят, кто что скажет по поводу такого кодстайла (пример так, либо с проверкой на что-либо ещё), когда первая часть условия — на одной строке с сигнатурой (без переноса, телеграм сам перенёс, конец сигнатуры на else {): fun someFunction(param: Int) = if (param != 42) someFunction(param+1) else { // other code } Ну и аналогичное с when: насколько с этим неудобно работать/неудобно читать остальным?

я б переносил все что за = на следующую строку, за исключением того когда у тебя все в одну строчку умещается

но ваще у меня попоболь по поводу inline if

и скобки вокруг someFunction() бы сделал

тогда сразу тебе читаемость

fun someFunction(param: Int) = if (param != 42) { someFunction(param+1) } else { // other code }

this

тогда сразу тебе читаемость

if как выражение не может не иметь else, потому для него отпадает необходимость в фигурных скобках

это привычка, а не читаемость ;)

либо я тебя не понял, либо такое if (someBooleanValue) { foo = "bar" } невалидно

а оно валидно

вот такое не валидно: foo = if(bool) { "bar" }

если твой иф возвращает что-то отличное от Unit то да

Друг, ты бы перестал вклиниваться в диалоги, не читая контекст. Я именно это и утверждаю.

канальчик, а никто не вкуривал как под капотом работает ретрофит? – мне интересная та часть где я ему говорю что вот мол тебе GsonConverter и он начинает мне генерить соответствующие объекты?

ок

мне именно TypeAdapter интересен

хотя это андроид и гипотетически я ошибся чатиком

канальчик, а никто не вкуривал как под капотом работает ретрофит? – мне интересная та часть где я ему говорю что вот мол тебе GsonConverter и он начинает мне генерить соответствующие объекты?

Я вкуривал. В чём вопрос? (Android тут вообще не при чём)

мне именно TypeAdapter интересен

TypeAdapter — это вообще часть Gson.

layer0[2].fill(Tile(atlas.rndTile), 0, layer0[2].size) при такой заливке Tile(atlas.rndTile) выполняется всего один раз, как сделать что бы Tile(atlas.rndTile) повторился layer0[2].size раз ?

или каким другим путем заполнить второй уровень массива

в идеале было бы не плохо добавить IntRange в индексы, типа: val start = 0 val end = layer0[3].size layer0[3][start..end] = Tile(atlas.rndTile) ?

Я вот не особо понял, что требуется сделать.

заполнить второй уровень массива layer0[N][N2]

fill же заполняет всё от layer0[2][0] до layer0[2][size], что теперь нужно сделать?

Tile(atlas.rndTile) при fill выполняется только один раз, а нужно size раз

так как там береться рандомный регион текстуры

то есть если мне все заолнить null то все ок, но если разными объектами класса Tile то чет не канает

Вообще fill не подходит. val array = layer0[2] for (i in array.indices) array[i] = Tile(...)

хотел как короче :( в одну строку

то есть без for

inline fun <T> Array<T>.fill(getT: (Int) -> T) { for (i in indices) this[i] = getT(i) }

круто ))

спасиб)

а inline это хорошо или плохо ?

а inline это хорошо или плохо ?

inline — это модификатор

lazy умеет принимать параметры?

https://kotlinlang.ru/docs/reference/inline-functions.html почитал и не понял, палка о двух концах

https://kotlinlang.ru/docs/reference/inline-functions.html почитал и не понял, палка о двух концах

Что именно не понял? Так и есть, ничего однозначного не бывает.

может повысить производительность, но и повысить кол-во сгенерированного кода

а кто такие разумные пределы... не совсем ясно

а кто такие разумные пределы... не совсем ясно

Разумные пределы — это когда либо мало кода (мда, очень точно выражаюсь), либо объёмы кода в передаваемой функции ощутимо больше собственного кода inline-функции.

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

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

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

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

Так вроде при компиляции код из метода вставят по месту использования и всё

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

> пусть функция торчит заранее в памяти вообще не то

Так вроде при компиляции код из метода вставят по месту использования и всё

мы это и обсуждаем

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

В JVM нет спомоба передать функцию. Только объект.