Я посмотрел вчера reactive чтототам лайбари от Елизарова, но там было преобразование корутин в моно и флюкс, но не наоборот

А вот каналы похоже на то, гляну

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

Да, типы остаются, только вот они остаются в виде: "верь мне, компилятор, я инженер". В скале это не так заметно, а если включить имплиситы в Haskell - сразу становится понятно, что без явного указания сигнатур они не работают, но компилируются => компилятор не способен корректно типы вывести и эта обязанность ложится на человека.

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

Вобщем то в любом более менее большом проекте без ide не разберёшься

это да

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

Ну, это странно, там на самом деле довольно жестко типы указываются. То, что прилетает в функцию с имплиситом и то, для каких типов имплисит определен - этого должно вполне хватать, чтобы правильно вывести тип

Импилситы (динамическое связывание) можно проверить на корректность только в рантайм, да и то не всегда. В Haskell, если сигнатура имплисита не указана - всё компилируется, только функции с имплиситами дают неверные результаты.

Я посмотрел вчера reactive чтототам лайбари от Елизарова, но там было преобразование корутин в моно и флюкс, но не наоборот

https://github.com/Kotlin/kotlinx.coroutines/tree/master/reactive/kotlinx-coroutines-reactive publish принимает саспенд-функцию и выкатывает Publisher, Publisher.openSubscription из паблишера делает как раз канал. В сорцах и реализация канала есть рядом.

Ну, это странно, там на самом деле довольно жестко типы указываются. То, что прилетает в функцию с имплиситом и то, для каких типов имплисит определен - этого должно вполне хватать, чтобы правильно вывести тип

Подробнее надо копать в причинах. Я посмотрел примеры в доке Хаскеля по имплиситам, как оно может косячить, с объяснениями, но времени на свои эксперименты, чтобы "прочувствовать боль", не было.

https://github.com/Kotlin/kotlinx.coroutines/tree/master/reactive/kotlinx-coroutines-reactive publish принимает саспенд-функцию и выкатывает Publisher, Publisher.openSubscription из паблишера делает как раз канал. В сорцах и реализация канала есть рядом.

? то, что нужно

Понял только по примерам, что боль есть и надо сильно думать, прежде чем использовать, на тему: "а оно тебе надо?"

Так какое резюме? Имплиситы убрать, PoC переписать? Потому что я помню в KEEP-87 обсуждались разные подходы.

Я думаю, что если в Котлине все-таки будут делать имплиситы, то сначала сделают к ним качественную систему типов

имплиситы - в том виде, в котором они есть в Скале и в том виде, как они представлены в KEEP-87, через with

Импилситы (динамическое связывание) можно проверить на корректность только в рантайм, да и то не всегда. В Haskell, если сигнатура имплисита не указана - всё компилируется, только функции с имплиситами дают неверные результаты.

Возможно это проблема исключительно хаскеля, потому что в scala если есть несколько вариантов, то компиляция не проходит, если компиляция прошла, то значит всё будет ок

Возможно это проблема исключительно хаскеля, потому что в scala если есть несколько вариантов, то компиляция не проходит, если компиляция прошла, то значит всё будет ок

Да, в том виде, как я описал, она специфична для Хаскеля, так как он очень редко требует явного указания типа чего-либо. Выводится всё, включая типы параметров функции. При этом для имплиситов оно выводится не верно, что вскрывает более глубокую проблему: автоматическая проверка корректности не возможна для имплиситов, нужно руками подсказывать типы компилятору. В Скале чаще надо подсказывать типы компилятору, но это не избавляет от проблемы: компилятор проверит подсказки как сможет, посчитает, что всё ок, но подсказки не верные.

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

Система типов для имплиситов вместо безопасности даёт иллюзию безопасности. Вот в чём проблема.

Зачем там вообще имплиситы, если есть тайпклассы? (которые по идеи уникальны) Ну и как бы с котлином все так надо скалу сравнимать, тк ни там ни там нет Х-М

Кто использует Kotlin/JS, использовали с Node.JS? Расскажите как оно))

и заодно с ангуляром

Да, типы остаются, только вот они остаются в виде: "верь мне, компилятор, я инженер". В скале это не так заметно, а если включить имплиситы в Haskell - сразу становится понятно, что без явного указания сигнатур они не работают, но компилируются => компилятор не способен корректно типы вывести и эта обязанность ложится на человека.

звучит как что-то ненадежное

Кто использует Kotlin/JS, использовали с Node.JS? Расскажите как оно))

Походу сильно не хватает обёрток для всяких нужных либ. Либо через dynamic прикручивать, что очень неудобно, либо обёртки генерить и допиливать

Ну, у меня работает хелоуворлдный сервер на Node.js + Express + MongoDB

Я осилила, при том, что в веб программировании совершенно не рублю и JS тоже не знаю. Но я смогла только из большой любви к Котлину ?‍♀️

Ну, у меня работает хелоуворлдный сервер на Node.js + Express + MongoDB

ща бы бэк пилить на kotlin/js

чисто что бы сказть "я так умею"?

ща бы бэк пилить на kotlin/js

ща бы писать «ща бы»

ща бы писать «ща бы»

ага

ща бы бэк пилить на kotlin/js

Цели я оставлю за кадром

фразу портишь

Не для прода, ясен пень

Так какое резюме? Имплиситы убрать, PoC переписать? Потому что я помню в KEEP-87 обсуждались разные подходы.

Кстати, POC странный, в кипе правила резолюции написаны так: инстанс тайпкласса должен быть определен в файле с тайпклассом, либо в файле с сущностью, для которой определяется инстанс тайпкласса. В POC зачем-то смотрят в компаньон, в пакет и сабпакеты

Я нодой зависимости подтягивал через kotlin-frontend. После мавена смотрится абсолютно убого, но это проблема ноды а не котлины.

Но зато в ноде есть ^ ? (крышечки)

Да... это точно ... с нодой всем крышка ...

Разве в гредле нет? Плюсик точно был

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

Я думаю что только за нормальную сборку kotlin-js можно памятник поставить.

Я думаю что только за нормальную сборку kotlin-js можно памятник поставить.

А у меня всё равно всё обросло разными package.json, а kotlin-frontend-plugin пришлось выпилить, потому что доставлял кучу проблем ?ъ

У меня все работало., но у меня не было серверной части, только собственно frontend

Серверную часть писать на JS при живом кторе - это какой-то изврат

У меня все работало., но у меня не было серверной части, только собственно frontend

у меня этот плагин тоже только на фронте был. Но там были странные плавающие косяки, которые далеко не во всех окружениях проявлялись и не при всех настройках. Ну и фактор кривизны моих рук тоже стоит учитывать, конечно ?‍♀️

Фактор окружения - это косяк ноды. Я думаю, что он не лечится. Собирать только на одном конкретном компьютере и не дышать.

Серверную часть писать на JS при живом кторе - это какой-то изврат

...при живых JVM, BEAM, Rust.

Я имею в виду если и так в котлиновской экосистеме.

Фактор окружения - это косяк ноды. Я думаю, что он не лечится. Собирать только на одном конкретном компьютере и не дышать.

А Karma включали?

да. авторелоад работал.

Там куча бойлерплейта для этого хот релоада, я его не понимаю, но просто тупо скопировал из премера в kotlin-frontend. Магия

Там куча бойлерплейта для этого хот релоада, я его не понимаю, но просто тупо скопировал из премера в kotlin-frontend. Магия

За хот релоад разве не Webpack отвечает? Karma это тест раннер

а

Значит наверное нет. У меня двух-платформенный проект, тесты все на JVM гонял

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

Я думаю, что ключевая проблема в том, что в JS нет понятия компиляции и сборки. Там вообще все происходит в рантайме. В котлин/градл наоборот все кроме непосредственно исполнения вынесено в сборку. Конфликт идеологий.

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

А как сделать экстеншн для самого класса? Чтобы можно было сделать так: MyClass.extensionCall()

для класса ?

Пытаюсь сделать экстеншн к классу так: inline fun <reified T: Class<*>> T.getLogger() = LoggerFactory.getLogger(T::class.java)

ага для класса

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

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

хочешь сделать экстеншен к компаньону?

Если компаньон есть, то fun MyClass.Companion.getLogger() = .... Если это generic, даже reified, то никак, ибо компаньона может не быть.

хочешь сделать экстеншен к компаньону?

Боюсь у slf4j логгера нет компаньона (

Да, к Java-классам экстеншны писать не получится.

ERROR: S client not available

Вообще в итоге я хотел так сделать: val logger = MyCoolClass.logger

чтобы не писать так: val logger = LoggerFactory.getLogger(MyCoolClass::java.class)

почему бы не передавать хотя бы this в подобного рода функцию?

ещё как вариант можно подключить одну из десятка обёрток для котлина

Вообще в итоге я хотел так сделать: val logger = MyCoolClass.logger

https://github.com/MicroUtils/kotlin-logging Посмотри здесь, может либа пойдёт, или найдёшь внутри что-то, что тебе нужно

только хотел скинуть

чтобы не писать так: val logger = LoggerFactory.getLogger(MyCoolClass::java.class)

У меня вот так получилось: class C inline fun KClass<*>.getLogger() = LoggerFactory.getLogger(this.java) fun main(args: Array<String>) { C::class.getLogger() }

Или так: class C val KClass<*>.logger get() = LoggerFactory.getLogger(this.java) fun main(args: Array<String>) { C::class.logger }

Без ::class не получится, так как <имя_класса>.<идентификатор> - это обращение к идентификаторам, объявленным в компаньоне.

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

Да... это точно ... с нодой всем крышка ...

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

Кому обновление плагина на 1.3 прилетело?

Кому обновление плагина на 1.3 прилетело?

Переключись на экспериментальную ветку и прилетит

Пытаюсь сделать экстеншн к классу так: inline fun <reified T: Class<*>> T.getLogger() = LoggerFactory.getLogger(T::class.java)

inline fun <reified T: Any> T.getLogger() = LoggerFactory.getLogger(this.javaClass.name)

Все равно, LoggerFactor.getLogger(class) использует LoggerFactor.getLogger(String)

inline fun <reified T: Any> T.getLogger() = LoggerFactory.getLogger(this.javaClass.name)

Так не выйдет. Ресивером в этом случае будет объект класса, а надо, чтобы класс

Так не выйдет. Ресивером в этом случае будет объект класса, а надо, чтобы класс

Ясно-понятно. Без класса счастье не счастье

Ясно-понятно. Без класса счастье не счастье

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

Или так: class C val KClass<*>.logger get() = LoggerFactory.getLogger(this.java) fun main(args: Array<String>) { C::class.logger }

Так неплохо

Пытаюсь сделать экстеншн к классу так: inline fun <reified T: Class<*>> T.getLogger() = LoggerFactory.getLogger(T::class.java)

Секундочку, а почему не fun Class<*>.getLogger() = LoggerFactory.getLogger(this)?

Зачем там reified дженерик?

Ну я пробовал и KClass, ну в общем без ::class я так понял, что не обойтись

а, понял

inline fun <reified T> getLogger() = Logger.getLogger(T::class.java.name) такой вариант уже был? :)

inline fun <reified T> getLogger() = Logger.getLogger(T::class.java.name) такой вариант уже был? :)

Да, так можно: class C inline fun <reified T> getLogger() = LoggerFactory.getLogger(T::class.java) fun main(args: Array<String>) { getLogger<C>() }

Давно хочу спросить, зачем группе логотип с этим чайником?

сгвспотсвуоао

Это же раритет

Первый логотип?!

Если не ошибаюсь

Если не ошибаюсь

Да, один из первых кажется

Ну не ассоциируется сейчас же