В моем примере, пишем выражение в контесте Double-ов, получема выражение для Double-ов (без боксинга!). Пишем для комлексных - получаем для комплексных

Так это же и на тайп классах делается

Так это же и на тайп классах делается

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

А, да

Всё, нафиг. Уже забывать стал, о чём говорили

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

хм, но ведь member declaration есть? что мешает s/this/parameter1

Я так понял, что сейчас мембер экстеншены просто объявляются методами класса со специальной пометкой, что первый параметр - ресивер. Для того, чтобы их было много, надо менять все метаданные.

Я так понял, что сейчас мембер экстеншены просто объявляются методами класса со специальной пометкой, что первый параметр - ресивер. Для того, чтобы их было много, надо менять все метаданные.

смотри, обычные экстеншны - статик методы с первым параметром как ресивером

что мешает сделать статик метод с двумя параметрами-ресиверами?

Речь о мемберах.

с термя

Не знаю. Думаю, что структура метаданных.

погодь погодь

мы же вроде не о member говорили

а о вложенных экстеншнах

А это одно и тоже. Два ресивера == мембер экстеншен

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

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

Сейчас это мембер экстеншен. Если будет двойной ресивер, то можно от этого термина вообще отказаться

Ну не совсем. Мембер эстеншен можно наследовать

Да, по видимости и наследованию разница есть, но по функциональности она сотрется

мембер экстеншн просто метод класса с первым параметром ресивером

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

@Harmonizr ты спрашивал про доки к компилятору, нашел что нибудь? А то у меня не получилось даже собрать kotlin, валится с Gradle daemon dissapeared

Можно теоретически на кодогенерации и на аннотациях сделать POC

И играться сколько хочется

Просто придется обойтись без интеллисенса :^)

Было бы хорошо. У меня есть интуитивное ощущение, что там море возможностей, но времени на кодогенерацию совершенно нет

В принципе, с точки зрения компилятора, конструкции вида fun A.B.C.foo() {...} можно "расахарить" в fun foo(a: A, b: B, c: C) {...} ну и там, где вызывается, тоже аналогично трансформировать при компиляции.

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

В принципе, с точки зрения компилятора, конструкции вида fun A.B.C.foo() {...} можно "расахарить" в fun foo(a: A, b: B, c: C) {...} ну и там, где вызывается, тоже аналогично трансформировать при компиляции.

Да, так обычные экстеншены работают. Вопрос технической реализации.

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

Проблема в том, что если есть что-то совсем новое, то не понятно, будет ли оно сильно полезно даже если не вредно. Правда я думаю, что от мультиресиверов плохо точно не будет. Им полно чисто практических применений и без всякой филосовии.

Проблема в том, что если есть что-то совсем новое, то не понятно, будет ли оно сильно полезно даже если не вредно. Правда я думаю, что от мультиресиверов плохо точно не будет. Им полно чисто практических применений и без всякой филосовии.

Ну понятно, что стрёмно добавлять то, на чём ещё никто шишек не набил

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

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

(нет)

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

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

а какая из фичей сложная?

Возможен ещё вариант с очень выразительным и простым

Возможен ещё вариант с очень выразительным и простым

Не, ну это конечно самый огонь. А есть что-то такое простое и крутое, чего в Котлине до сих пор нет?

тайпклассы :^D

Тайп классы по своей природе - очень простая концепция. Просто интерфейс, который можно реализовать где тебе хочется. Роды типов (higher kinded types) - это уже сложнее для понимания, но позволяет реализовывать максимально общие тайп классы.

Если бы они были простыми, они бы уже были

KEEP-87 в том виде, в котором он предложен, довольно страшненький, а это типа самое-самое крутое, что смогли придумать.

При этом саму идею я поддерживаю.

Если бы они были простыми, они бы уже были

Просто в текущем KEEP их перемешели с родами типов и имплиситами (?), а надо на три фичи разбить.

Воот. Это ж нужно в уже существующий язык вписать с минимальными фейспалмами как-то

Ну да, там страшное - это имплиситы. И лучше, чтобы их никогда не было

смотрю я на примеры arrow https://github.com/istonikula/realworld-api/blob/master/realworld-app/web/src/main/kotlin/io/realworld/profiles/Routes.kt#L78 и один вопрос только, а нафига?

имплиситы затащили потому что в arrow скалисты

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

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

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

это ж прям противоречит ценностям Котлина

ага

Поэтому его упорно отражают пока

В котлин комьюнити антискалистов больше, чем скалистов

смотрю я на примеры arrow https://github.com/istonikula/realworld-api/blob/master/realworld-app/web/src/main/kotlin/io/realworld/profiles/Routes.kt#L78 и один вопрос только, а нафига?

Вот кст не надо, Arrow довольно удобный

Уж по-крайней мере через Either/Try/Option ошибки собирать гораздо круче, чем в разных местах кода эксепшены отлавливать

https://github.com/istonikula/realworld-api/blob/master/realworld-domain/src/main/kotlin/io/realworld/domain/profiles/UseCases.kt#L70

Уж по-крайней мере через Either/Try/Option ошибки собирать гораздо круче, чем в разных местах кода эксепшены отлавливать

не бросайте их где не надо, и не придется отлавливать)

не бросайте их где не надо, и не придется отлавливать)

Забавно такое слышать

Уж по-крайней мере через Either/Try/Option ошибки собирать гораздо круче, чем в разных местах кода эксепшены отлавливать

Зачем в разных, когда есть main ??

Вопрос вкуса, но я пожалуй согласен с тем, что Either не нужен

func Open(name string) (file *File, err error) чет сразу вспомнил..

Забавно такое слышать

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

Зачем в разных, когда есть main ??

Ну рили, в новых корутинах еще проще стало ресурсы освобождать при ошибки/отмене. Поставил в корень web-контроллера try/catch и все.

А на реакторе?

Кстати, это забавно, но те самые байндинги Arrow, которые там выше можно было наблюдать, юзают корутины

А на реакторе?

я честно хз зачем он на бекенде нужен

я честно хз зачем он на бекенде нужен

SSE

сделал канал и пихай себе SSE

Ну оно и на реакторе также. Метод контроллера просто возвращает Flux и радуется

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

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

Вкусовщина

Вкусовщина

ради интереса попробуй кому-то обьяснить как работают корутины, и как работает реактор. а потом посадить писать асинхронный код..

я не знаю как на мобилках или фронте, но на бекенде от него больше вреда

Хех, как от rx на мобилках

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

(не для меня, да)

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

ради интереса попробуй кому-то обьяснить как работают корутины, и как работает реактор. а потом посадить писать асинхронный код..

ты намекаешь на то что на корутинах проще?

ты намекаешь на то что на корутинах проще?

утверждаю даже)

Но вообще говоря, я всё-таки не о тех ошибках говорил. Вот пример - контроллер получает какие-то данные, валидирует их, если не завалидировал - возвращает ошибку, потом пихает куда-то ещё, оттуда получает результат, который тоже может быть ошибкой. В зависимости от того, что за ошибка, контроллеру нужно вернуть определенный ResponseEntity. И как жить?

Но вообще говоря, я всё-таки не о тех ошибках говорил. Вот пример - контроллер получает какие-то данные, валидирует их, если не завалидировал - возвращает ошибку, потом пихает куда-то ещё, оттуда получает результат, который тоже может быть ошибкой. В зависимости от того, что за ошибка, контроллеру нужно вернуть определенный ResponseEntity. И как жить?

обработкой на верхнем уровне эксепшенов по типу?

Заниматься обработкой эксепшенов в котлине вообще неблагодарное дело, особенно когда есть sealed классы

Заниматься обработкой эксепшенов в котлине вообще неблагодарное дело, особенно когда есть sealed классы

Вообще не правда.

Это абсолютно разные вещи

Можно делать Seled эксепшены, конечно.

Заниматься обработкой эксепшенов в котлине вообще неблагодарное дело, особенно когда есть sealed классы

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

Заниматься обработкой эксепшенов в котлине вообще неблагодарное дело, особенно когда есть sealed классы

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

Заниматься обработкой эксепшенов в котлине вообще неблагодарное дело, особенно когда есть sealed классы

Главное, что в корутинах у тебя самый обычный exception handling, а вот в rx это все under the hood и нужно хорошо разбираться в Rx чтобы быть уверенным в результате. Лично я с Rx никогда не уверен что я правильно написал.

Главное, что в корутинах у тебя самый обычный exception handling, а вот в rx это все under the hood и нужно хорошо разбираться в Rx чтобы быть уверенным в результате. Лично я с Rx никогда не уверен что я правильно написал.

в Rx наоборот ошибки веселей обрабатывать, все сразу в onError падает. Я когда пересел на корутины на андроиде с непривычки потерял обработку ошибок ?

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

Нет, если завернут в какую-нибудь монаду а-ля Try

в Rx наоборот ошибки веселей обрабатывать, все сразу в onError падает. Я когда пересел на корутины на андроиде с непривычки потерял обработку ошибок ?

Если мы говорим про то чтобы обучить разработчика и что понятнее - то try/catch куда очевиднее

в Rx наоборот ошибки веселей обрабатывать, все сразу в onError падает. Я когда пересел на корутины на андроиде с непривычки потерял обработку ошибок ?

Плюсую. Очень непривычно стало.

Если мы говорим про то чтобы обучить разработчика и что понятнее - то try/catch куда очевиднее

Там вон выше написали, что люди поток выполнения исключениями контроллируют. Вот и польза от простоты

Там вон выше написали, что люди поток выполнения исключениями контроллируют. Вот и польза от простоты

и от этого rx лучше стал?)

Там вон выше написали, что люди поток выполнения исключениями контроллируют. Вот и польза от простоты

если исключения юзать как panic в го, то жизнь станет проще)

Я всем говорю, что у Rx и у корутин на самом деле разные юзкейсы. Но всё-таки плохой код на Rx встречается гораздо реже, чем когда люди исключения кидают

Вы учите язык, вы выучили try/catch, вы учите корутины - там try/catch, все понятно в этом плане. Вы учите язык, try/catch, вам дают rx, вас съел огр.

Я всем говорю, что у Rx и у корутин на самом деле разные юзкейсы. Но всё-таки плохой код на Rx встречается гораздо реже, чем когда люди исключения кидают

Какие-то нерелевантные примеры. Мы говорим что проще выучить, что легче понимается. А не про то что и как заобьюзить.