видимо, выглядело как посылание подальше.
Аттрибуты из session считываются только в теле функции request

это не путь джедая

там есть настройка которая делает дефолтовый гедер, как вы любите - в одну строчку

А как вы решили проблему, что браузеры шлют херову тучу хедеров левых, вроде sec-fetch-mode
Или они на OPTIONS не делают такой дичи?

Я - никак, я не работал активно с ktor ещё :)

Но вроде пример выше это не браузер, а fetch API и там 4 хедера: Sec-Fetch-Dest Sec-Fetch-Mode Sec-Fetch-Site Sec-Fetch-User

Если это так (могу ошибаться, совсем не эксперт), то вроде можно и руками добавить в список. Хотя функция fetchHeaders() не помешает. Но может это и не проблема, может они действительно как-то сами вычищаются :)

Мне всё же кажется что оно не должно слать это гумно на Options, но ещё руки не добрались посмотреть.

Может кто-то подсказать, для чего фабричные функции MVar в arrow-kt возвращают Kind<F, MVar<F, A>>? Почему бы не вернуть просто MVar<F, A>?

MVar создаётся в каком-то контексте. Собственно этот контекст в сигнатуре и показан и из него внутри контекста можно вытащить. Пример есть в доке: https://arrow-kt.io/docs/apidocs/arrow-fx/arrow.fx.typeclasses/-concurrent/-m-var.html

Примечание - если сравнить например с аналогом в Хаскелле, то там будет тоже самое, просто вместо произвольного контекста пришит IO: https://hackage.haskell.org/package/base-4.12.0.0/docs/Control-Concurrent-MVar.html

Потому что создание мутабельного состояния должно происходить внутри контекста

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

Ребята, добрый день. Я до недавнего времени писал на Scala, но сейчас у меня Java проект и поэтому вопрос. Я пишу либу на Kotlin, будет она использоваться и в джаве и в котлине. Как мне быть с Collection? Если в параметрах моих интерфейсов использоваться джавовскую то я не смогу в котлине использовать arrayListOf при передаче параметра. Это как-то элегентно решается или придётся делать отдельные интерфейсы с обёртками?

Спасибо.

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

К сожалению это пока не вариант.

Почему?

Почему? В Котлине будут понятные типы, в джавы это будет выглядеть как джавовые родные типы. Тут подробнее: https://kotlinlang.org/docs/reference/java-interop.html#mapped-types

Потому-что 30 тысяч строк джава кода и 80 программистов работает. Я не могу просто ввалиться и начать мешать коллекции :) Т.е. это не технологический вопрос, а политический.

Так у вас код на джаве или на котлине?

Всё на джаве. Я пишу отдельный модуль на Kotlin.

Ну так и используйте котлиновские коллекции в коде на котлине. Что мешает?

Ладно, давайте вернёмся к моему исходному вопросу. Ещё варианты для interop-а коллекций есть в Kotline ?