норм

Давайте не порождать флуд. И, тем более, флуд стикерами.

Ай нид хелп. Есть интерфейс на джаве ( с 2 методами) Пытаюсь тестить (с мокито) private var processCallback: BusinessCallback? = null private val logic : BusinessLogic = mock { on { addListener(any()) } doAnswer { processCallback = it.getArgument<BusinessCallback>(0) } } Компилятор ругается на строчку processCallback = it.getArgument<BusinessCallback>(0) Ошибка: Expected a value of type Unit?

В соседнем тесте такая конструкция нормально работает

Мэджик

В соседнем тесте такая конструкция нормально работает

значит, не такая же)

Наверное doAnswer последней строкой должен что-то возвращать, а у тебя там присвоение. Попробуй добавить явный Unit: … oAnswer { processCallback = it.getArgument<BusinessCallback>(0) Unit } …

По идее не должен. Метод addListener void

Если это он https://github.com/nhaarman/mockito-kotlin/blob/master/mockito-kotlin/src/main/kotlin/com/nhaarman/mockito_kotlin/Mockito.kt#L105 то твоя лябда должна что-то возвращать, тк Котлин нет void, а = не считается за экспрешен возвращающий Unit

А, понял. А как создать пустой юнит?

Unit это синглтон (object)

Спасибо

Что думаешь?

Спасибо, теперь стало понятнее, но что будет если field2 не проходит валидацию и значения для него не существует? На сколько я знаю Delegates.notNull никак не может сказать заинитили его или нет(или написать).

ну можно использовать lateinit тогда у него можно узнать

Спасибо, теперь стало понятнее, но что будет если field2 не проходит валидацию и значения для него не существует? На сколько я знаю Delegates.notNull никак не может сказать заинитили его или нет(или написать).

всегда можно напистаь своего делегата

всегда можно напистаь своего делегата

примерно это и ждал услышать)

ну можно использовать lateinit тогда у него можно узнать

разве? там вроде уже с новой версии котлина такое можно, но не в текущей, сейчас проверю

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

примерно это и ждал услышать)

что совсем не сложно

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

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

Добрый вечер, обновил студию теперь при попытке добавить addAll в ArrayAdapter<String> лист List<String> выпадает ошибка Error:(87, 33) Unresolved reference. None of the following candidates is applicable because of receiver type mismatch: public fun <T> MutableCollection<in ???>.addAll(elements: Array<out ???>): Boolean defined in kotlin.collections public fun <T> MutableCollection<in ???>.addAll(elements: Sequence<???>): Boolean defined in kotlin.collections public fun <T> MutableCollection<in String>.addAll(elements: Iterable<String>): Boolean defined in kotlin.collections

как решить? раньше работало adapter.addAll(rubList!!.map { it.rubTitle } ) ,rubTitle String

что совсем не сложно

честно говоря покопал и ничего лучше обсервабла из примера не нашел https://discuss.kotlinlang.org/t/how-to-know-if-a-not-null-variable-by-delegate-delegates-notnull-has-been-initialized/1542/2, но рефлексия наверное подождет пока что

Кажется, в 1.2 есть возможность получить делегата.

Кажется, в 1.2 есть возможность получить делегата.

в 1.2 в лейтините есть подобный метод

Может кто использовал kmongo - есть ли какой-то вменяемый способ используя его и jackson вытащить вложенные элементы документа?

Всем привет, есть тут Kotlin евангелисты, который мне могут пояснить за пару вопросов? 1. Property vs. Function - в доке сказано, что функцию можно заменить на свойство, если функция не выбрасывает Exception, имеет константную сложность и идемпотентно. Идиоматически ли тогда будет заменить функцию, допустим getSize() на свойство size, если оно не будет "returns the same result over invocations"? Или я сильно строго воспринял рекомендации? (Понимаю, вопрос уровня табы vs. пробелы, но все же хотелось бы узнать, как стоит писать правильно с точки зрения Kotlin). 2. Нигде не заметил в документации уточнений оптимизируются ли цепочки high-order функций при компиляции. Т.е. если вызывать list.filter { it > 10 }.map { element -> element * 2 } сколько раз будет выполнен полный проход по списку? Подозреваю, что один, но хотелось бы пруфов из доки/книг/выступлений/etc.

1. главное чтобы рандом твой size не возвращал, а показывал состояние обьекта на момент вызова 2. в твоем примере будет создана временная коллекция после filter

Функц. методы над коллекциями не леневые, создают промежуточные коллекции. Используй sequence

когда много айтемов

Когда дорого. Обычно, не часто это требуется

Ну, это понятно, что на списке из 10 элементов я заморачиваться не буду.

Всем привет, есть тут Kotlin евангелисты, который мне могут пояснить за пару вопросов? 1. Property vs. Function - в доке сказано, что функцию можно заменить на свойство, если функция не выбрасывает Exception, имеет константную сложность и идемпотентно. Идиоматически ли тогда будет заменить функцию, допустим getSize() на свойство size, если оно не будет "returns the same result over invocations"? Или я сильно строго воспринял рекомендации? (Понимаю, вопрос уровня табы vs. пробелы, но все же хотелось бы узнать, как стоит писать правильно с точки зрения Kotlin). 2. Нигде не заметил в документации уточнений оптимизируются ли цепочки high-order функций при компиляции. Т.е. если вызывать list.filter { it > 10 }.map { element -> element * 2 } сколько раз будет выполнен полный проход по списку? Подозреваю, что один, но хотелось бы пруфов из доки/книг/выступлений/etc.

Я бы так сказал: свойство — это данные, функция — поведение.

Я бы так сказал: свойство — это данные, функция — поведение.

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

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

Свойства тоже неплохо себя чувствуют без полей.

Свойства тоже неплохо себя чувствуют без полей.

Ну да

Функц. методы над коллекциями не леневые, создают промежуточные коллекции. Используй sequence

Спасибо за уточнение. Я почему-то считал, что high-order функции работают, как синтаксический сахар для for и при компиляции ужимаются, по возможности, в один цикл (без промежуточных коллекций и лишних обходов). Теперь стало все стало ясно.

Спасибо за уточнение. Я почему-то считал, что high-order функции работают, как синтаксический сахар для for и при компиляции ужимаются, по возможности, в один цикл (без промежуточных коллекций и лишних обходов). Теперь стало все стало ясно.

Лениво как стримы работает Sequence

Лениво как стримы работает Sequence

Спасибо, уже луркаю

Спасибо за уточнение. Я почему-то считал, что high-order функции работают, как синтаксический сахар для for и при компиляции ужимаются, по возможности, в один цикл (без промежуточных коллекций и лишних обходов). Теперь стало все стало ясно.

Посмотри исходники, никакой магии там нет (хотя HotSpot может и оптимизирует что то)

1. главное чтобы рандом твой size не возвращал, а показывал состояние обьекта на момент вызова 2. в твоем примере будет создана временная коллекция после filter

1. А если мой класс - это абстракция над какой-нибудь сетевой штукой и вызов size может занять некоторое неконстантное время, тут стоит использовать проперти, или лучше использовать функцию?

1. А если мой класс - это абстракция над какой-нибудь сетевой штукой и вызов size может занять некоторое неконстантное время, тут стоит использовать проперти, или лучше использовать функцию?

"сетевая штука" может и исключение бросить. Конечно лучше метод, да ещё на корутинах ?

как котлин?:) хорош?)

как будто ехал на вонючем запоре и пересел на сверкающий феррари именно такие впечатления с перепрыга с java7

ну начинается

так ну правда же

а че на скалу не пересел пару лет назад

раз джава такая вонючая

так исторически слежалось

как будто ехал на вонючем запоре и пересел на сверкающий феррари именно такие впечатления с перепрыга с java7

Точная аналогия, как раз и расход топлива возрос

Точная аналогия, как раз и расход топлива возрос

дефайн топливо. Если время компиляции, ну максимум процентов на 10 а если читаемость, время написания, стоимость написания, то все лучше

дефайн топливо. Если время компиляции, ну максимум процентов на 10 а если читаемость, время написания, стоимость написания, то все лучше

Производительность

inline и нормально

производительность котлина не хуже джавы

просто смешно когда говорят что джава уж полное дерьмо

А еще запором может каждый управлять, а вот феррари нет

просто смешно когда говорят что джава уж полное дерьмо

джава не полное дерьмо. Каждый день пишу на ней. Язык хороший, но императивная седьмая уже насквозь устаревшая

проекты с более древней джавой я и не говорю

а на какую платформу пишешь?

А еще запором может каждый управлять, а вот феррари нет

разница - 2 недели неспешного решения kotlin koans. Порог входа очень низок, если ты уже java developer

с 7

серверная разработка заднего конца

разница - 2 недели неспешного решения kotlin koans. Порог входа очень низок, если ты уже java developer

Ну вот, за две недели можно много полезных фич делать, а тут надо разраба обучать при передаче проекта

а почему нельзя на 8-9 перейти? вот в андроиде ест ьобьективная причина

а на бекенде с чем связано?

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

роу типы всякие тому подтверждение

Ну джава 8 не дает нуллабилити, например

И прочие фичи котлина

серьезно? 2 недели это ничего. Зато повышенный выхлоп в читаемости, скорости написания и более безопасный с точки зрения код

а вот если разработчик принципиально не хочет учить ничего нового, то это уже вопрос к самому разработчику

я имею в виду почему с 7 не перейти на 8 которая уже приятная

Безопасный только при прямых руках, а с прямыми руками и на джаве безопасно люди пишут

а почему нельзя на 8-9 перейти? вот в андроиде ест ьобьективная причина

миллиард серверов без виртуализации с 7 джавой в продакшене, которые никто не хочет обновлять докерить тоже - только в CI и CD до прода есть докер

банк, фиг ли

лан, пора бежать, всем спасибо за срач :)

тоесть перейти на котлин намного легче чем поднять версию джавы?

миллиард серверов без виртуализации с 7 джавой в продакшене, которые никто не хочет обновлять докерить тоже - только в CI и CD до прода есть докер

Даже секьюрити апдейты не ставите?

тоесть перейти на котлин намного легче чем поднять версию джавы?

Да. Опсам не нужно будет работать, чего они делать в принципе не хотят

Даже секьюрити апдейты не ставите?

Не знаю. Но честно не думаю

странный у вас банк))

Не знаю. Но честно не думаю

А что за банк?))

на безу пох, опсы не хотят работать))

балаган))

devops, это когда сами и девелопят ;) у вас похоже обычные админы

Поэтому я и сказал "опсы"

Девопс у нас до прода

не смотря на все совместимости, проект на котором я сейчас работаю, работает на 7 и не собирается на 8 и не стартует

так что для больших проектов часто всё не так просто