val a = new ArrayList(); val a2 = new ArrayList<>();

первый вариант — это сырой тип, который после Java 1.5 вообще не стоит использовать.

вывода типов там и в помине нет

первый вариант — это сырой тип, который после Java 1.5 вообще не стоит использовать.

ну вот я про вот это

это баг)

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

это баг)

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

Почему не компилируется такой пример? fun foo(a: Boolean, b: Boolean) = print("$a, $b") fun main(args : Array<String>) { val a = 1 val b = 2 val c = 3 val d = 4 foo(c < a, b > d) } ругается: Unresolved reference: c да, это можно починить расставив скобки, но просто интересно, а почему компилятор все-таки не может найти c?

Я дотошный. Резюмируем - в коде нет ни синтаксических, ни семантических ошибок, тем не менее, он не компилируется. Это плохо.

Я дотошный. Резюмируем - в коде нет ни синтаксических, ни семантических ошибок, тем не менее, он не компилируется. Это плохо.

проблема... а вот в рантайме словить самое оно

котлин как раз про не компилюсь

Я дотошный. Резюмируем - в коде нет ни синтаксических, ни семантических ошибок, тем не менее, он не компилируется. Это плохо.

это мозг говорит что их нет, но по факту есть вызов функции которая принимает тип с с дженериком, кооторого нет, и еще непонятная d

это мозг говорит что их нет, но по факту есть вызов функции которая принимает тип с с дженериком, кооторого нет, и еще непонятная d

>>> fun foo(a: Boolean, b: Boolean, c: Boolean) = println("$a, $b, $c") >>> val a = 1 >>> val b = 2 >>> val c = 3 >>> val d = 4 >>> foo(a < b, true, c > d) true, true, false

тип никак не может называться true :)

тип никак не может называться true :)

Да, "систему" не обойти ) >>> foo(a < b, `true`, c > d) ... ...

Ой, точно, может, но с бэктиками.

Ой, точно, может, но с бэктиками.

Нене, все верно, оно работает "в своей логике", многоточия в repl - это фактически ошибка парсера/компилятора

Да, "систему" не обойти ) >>> foo(a < b, `true`, c > d) ... ...

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

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

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

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

Да собственно у меня это и был посыл - true такой же терм, как идентификатор, парсер должен пойти по ветке разбора логических выражений и аппликации функции, а не дженериков

Да собственно у меня это и был посыл - true такой же терм, как идентификатор, парсер должен пойти по ветке разбора логических выражений и аппликации функции, а не дженериков

просто парсер, я так думаю, выводит сначала типы

Да собственно у меня это и был посыл - true такой же терм, как идентификатор, парсер должен пойти по ветке разбора логических выражений и аппликации функции, а не дженериков

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

Честно говоря, в Java достаточно редко вызываются дженери-методы.

Ага, пока не сталкиваешься с тем, что в не очень сложной цепочке со стримами javac не может вывести тип. И тут код превращается в кровавое месиво.

Ага, пока не сталкиваешься с тем, что в не очень сложной цепочке со стримами javac не может вывести тип. И тут код превращается в кровавое месиво.

Мне понравился упоротый пример с итератором (это же SAM-интерфейс): for (Whatever w : smth::createIterator)

Посоны, а кто-нибудь сталкивался с тем что не получается замокать метод, который принимает функцию? onErrorProcessSingle(error: Throwable, errorClass: Class<E>, customHandler: () -> Single<T>): Single<T>

пробую как-то так: whenever(errorHandler.onErrorProcessSingle(socketException, any<Class<ImageNPayException>>(), any<() -> Single<CardApiModel>>())) .thenReturn(Single.error(NoInternetImageNPayException(socketException)))

Не мокается

А что говорит хоть?

Не мокАется?

Простите, вырвалось

А что говорит хоть?

Просто падает на вызове этого метода

Ну то есть как-будто не сработало мокирование

Не мокАется?

Поглубже окунать пробовал, все равно не мокАется ага

Как гусь, сухой из воды(

а не пробовал с типовыми аргументами any играться?

или заменить на anyObject()

а не пробовал с типовыми аргументами any играться?

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

или заменить на anyObject()

Я использую Котлин мокито

Которое от nharman или как его там

Я использую Котлин мокито

ну а что мешает мокито напрямую один раз поюзать?

ну а что мешает мокито напрямую один раз поюзать?

Пробовал, не помогает, anyObject() не работает в котлине из-за налл сейф на уровне типа

Пришлось не мокировать, а использовать реальный объект, что по сути не правильно

Моки это вообще зло (и rx тоже ?)

а рх че?

пробую как-то так: whenever(errorHandler.onErrorProcessSingle(socketException, any<Class<ImageNPayException>>(), any<() -> Single<CardApiModel>>())) .thenReturn(Single.error(NoInternetImageNPayException(socketException)))

А вот первый аргумент - вполне себе инстанс класса, у которого, сомневаюсь, что переопределен equals. Может быть в этом дело?

А вот первый аргумент - вполне себе инстанс класса, у которого, сомневаюсь, что переопределен equals. Может быть в этом дело?

Это SocketTimeoutException

Это SocketTimeoutException

Предлагаю попробовать any<Class<SocketTimeoutException>>() - вот об этом я

Предлагаю попробовать any<Class<SocketTimeoutException>>() - вот об этом я

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

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

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

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

Вполне вероятно?

а рх че?

По тому что не нужен ?‍♀️ rx.Single очевидно заменяется базовыми корутинами, а observable каналами

а реактор?

А реактор вроде и не про то

это таже рх джава

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

А то рх джава сильно на ведроид смотрит

ну реактор ваще по этой самой причине и повился

По тому что не нужен ?‍♀️ rx.Single очевидно заменяется базовыми корутинами, а observable каналами

Кажлый раз спрашиваю: а хитрые комбайны? А ещё всякие вещи именно для управления стримами их трансформациями?

Я просто оставлю это здесь как пример того, что может Kotlin, и как не надо на нём писать: typealias Action = () -> Unit infix operator fun Unit.plus(s: String) = print(" $s") infix operator fun Unit.plus(next: Action): Action = print(" ") go next infix fun Unit.go(next: Action): Action = next val we: Action = { print("We") } infix fun Action.are(the: Action): Action = this() + "are" + the val the: Action = { print("the") } infix fun Action.best(programmers: Action): Unit = (this() + "best" + programmers)() val programmers: Action = { print("programmers") } val sentence = we are the best programmers fun main(args: Array<String>) = Unit

Кажлый раз спрашиваю: а хитрые комбайны? А ещё всякие вещи именно для управления стримами их трансформациями?

Мы сейчас про всякие single/completable/maybe или про настрощие стримы типа observable/flow? Думаю, все согласятся что стримы из [0..1] элементов, ну очевидно не нужны. А вот по поводу "бесконечных", можно подискутировать.

Я просто оставлю это здесь как пример того, что может Kotlin, и как не надо на нём писать: typealias Action = () -> Unit infix operator fun Unit.plus(s: String) = print(" $s") infix operator fun Unit.plus(next: Action): Action = print(" ") go next infix fun Unit.go(next: Action): Action = next val we: Action = { print("We") } infix fun Action.are(the: Action): Action = this() + "are" + the val the: Action = { print("the") } infix fun Action.best(programmers: Action): Unit = (this() + "best" + programmers)() val programmers: Action = { print("programmers") } val sentence = we are the best programmers fun main(args: Array<String>) = Unit

Откуда брать определение go?

infix fun Unit.go(next: Action): Action = next

infix fun Unit.go(next: Action): Action = next

А, понятно, я в repl скопипастил просто А букв много

Мы сейчас про всякие single/completable/maybe или про настрощие стримы типа observable/flow? Думаю, все согласятся что стримы из [0..1] элементов, ну очевидно не нужны. А вот по поводу "бесконечных", можно подискутировать.

Нужны ?

Нужны ?

Вот, кстати, в реакторе оно лучше сделано. А вообще-то не нужны

Мы сейчас про всякие single/completable/maybe или про настрощие стримы типа observable/flow? Думаю, все согласятся что стримы из [0..1] элементов, ну очевидно не нужны. А вот по поводу "бесконечных", можно подискутировать.

Конечно настоящие. Ну, completable еще нужен и он тоже может быть бесконечным, а single и maybe просто удобны, хотя без них вполне можно обойтмсь

ERROR: S client not available

Mono-то не нужны?

Вот моно это как раз адекватная монада, не эти нариковые стримы из 0 или 1 элемента

Конечно настоящие. Ну, completable еще нужен и он тоже может быть бесконечным, а single и maybe просто удобны, хотя без них вполне можно обойтмсь

Обратись можно перфокартами, но зачем отходить от удобства.

Обратись можно перфокартами, но зачем отходить от удобства.

Ну не, чистый single или maybe реально заменяется корутиной. Для комбинирования с другими стримами да, удобно. Но без них все равно можно жить.

Я просто оставлю это здесь как пример того, что может Kotlin, и как не надо на нём писать: typealias Action = () -> Unit infix operator fun Unit.plus(s: String) = print(" $s") infix operator fun Unit.plus(next: Action): Action = print(" ") go next infix fun Unit.go(next: Action): Action = next val we: Action = { print("We") } infix fun Action.are(the: Action): Action = this() + "are" + the val the: Action = { print("the") } infix fun Action.best(programmers: Action): Unit = (this() + "best" + programmers)() val programmers: Action = { print("programmers") } val sentence = we are the best programmers fun main(args: Array<String>) = Unit

Я в упор не вижу, что инициирует вычисления? Почему просто main не возвращает Unit?

Я в упор не вижу, что инициирует вычисления? Почему просто main не возвращает Unit?

val sentence = we are the best programmers

Вот на вычислении sentence всё и выводится

val sentence = we are the best programmers

А top-level, хитро

Спасибо

Конечно настоящие. Ну, completable еще нужен и он тоже может быть бесконечным, а single и maybe просто удобны, хотя без них вполне можно обойтмсь

> completable > он тоже может быть бесконечным Как так, у него только одно событие close. Он даже в рамках rx не нужен, тк спокойно эмулируется Single<Unit>

Я же говорил, что это пример, как не надо писать ?

> completable > он тоже может быть бесконечным Как так, у него только одно событие close. Он даже в рамках rx не нужен, тк спокойно эмулируется Single<Unit>

Ну типа observable.flatMapCompletable Но не суть, что делать с настоящим стримами? :)

Сегодня вмёрджили KEEP на inline-классы.

На секунду прочитал тайп-классы ? ... (чуть со стула не свалился)

Ну типа observable.flatMapCompletable Но не суть, что делать с настоящим стримами? :)

Сложный вопрос, я вроде и пишу приложения с реактивным-UI, но обхожусь без сложных RX/каналов вообще. (на react с elm архитектурой) Имхо если все же нужны реактивные-сримы, то в 99% случаем хватает и map/zip/flatMap из тех же каналов. P.S. Хотелось бы увидить реальный кейс где нужны сложные "операторы".

что еще за каналы?

https://github.com/Kotlin/kotlinx.coroutines/blob/master/coroutines-guide.md#channels

Ух ты! Долгожданный 2.0 на подходе https://github.com/spekframework/spek/releases

> completable > он тоже может быть бесконечным Как так, у него только одно событие close. Он даже в рамках rx не нужен, тк спокойно эмулируется Single<Unit>

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

Что бы сущностей не плодить (c) оккам. Зачем это Completable с дополнительным +100 методами и учитывая, как они хреново конвертятся друг в друга.

Пока все эти аргументы о "ненадобности" выглядят как «я не пользуюсь - значит не нужно»

Пока все эти аргументы о "ненадобности" выглядят как «я не пользуюсь - значит не нужно»

Погоди, зачем создавать частные случаи, если можно выразить общими средствами?

Давай создадим BiObservable, который можно объёрвить BiConsumer'ом, мы ж не лохи — кортежи/пары объёрвить.

Погоди, зачем создавать частные случаи, если можно выразить общими средствами?

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

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

Потому что весь этот Completable можно выразить как typealias Completable = Single<Unit>. Или хотя бы заэкстендить сингл.

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

Потому что весь этот Completable можно выразить как typealias Completable = Single<Unit>. Или хотя бы заэкстендить сингл.

А зачем, если есть такой же комплитабл уже готовый?

Нет, оно уже написано. Зачем сейчас, когда оно есть уже, говорить, что не надо.

Если бы он был в планах, я бы мог понять, хотя и то думаю можно оспорить, но сейчас чего

А зачем, если есть такой же комплитабл уже готовый?

А зачем грэдлу его скачивать на комп, дексеру его конвертить, рантайму его загружать и компилировать? Эту дырку от бублика нужно задепрекейтить и выпилить.

А зачем грэдлу его скачивать на комп, дексеру его конвертить, рантайму его загружать и компилировать? Эту дырку от бублика нужно задепрекейтить и выпилить.

О да, там же на комплитабл двадцать минут сборки идёт:)

О да, там же на комплитабл двадцать минут сборки идёт:)

RxJava состоит из таких излишеств чуть более, чем полностью.