а если прилага многослойная и тебе нужно прокинуть реально с нижнего слоя ошибку до самого юзера

это же геммор полный

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

а если прилага многослойная и тебе нужно прокинуть реально с нижнего слоя ошибку до самого юзера

Ну вот же блин, твоя монадка это сделает ничем не хуже Future, просто у неё будет два сорта ошибок - известный структурированный тип, и Throwable, который ждёт большой recover в конце с надеждой, что в нём перечислено всё, что нужно и тесты это подтверэдают

Идея в том, чтобы важные вещи переместить из второго сорта в первый

а есть такой же но с паттернами гоф?

окей в целом я понял

допустим есть DBIO - вставляет в базу - если срабатывает констрейт - это скажем так первый сорт, должен быть в Either, нету доступа к базе - это такой редкий случай - можно оставить в recovery

а если прилага многослойная и тебе нужно прокинуть реально с нижнего слоя ошибку до самого юзера

ну слюшай, мы ФП пишем или где? в хаскеле и других ФП как-то с этим справляются.

допустим есть DBIO - вставляет в базу - если срабатывает констрейт - это скажем так первый сорт, должен быть в Either, нету доступа к базе - это такой редкий случай - можно оставить в recovery

exactly

ну слюшай, мы ФП пишем или где? в хаскеле и других ФП как-то с этим справляются.

это не ответ) логику надо понимать четко)

sealed class Layer1Error SaneError1Layer1 SaneError2Layer1 ... SomeRandomUnexpectedShitLayer1

@odomontois так, давай еще раз абстрагируясь от своей монады и говоря языком DBIO/Future. Допустим из DBIO нужно прокинуть ошибку до самого юзера. Ошибка находится в Either - тут два вариант:

или мы все же кинем throw с крутой ошибкой и она быстро дойдет до самого верха

тогда смысла в either нету)

вообще есть смысл

потому что стектрейса далеко не всегда хватает и нужно доп инфой напихать

или мы все же кинем throw с крутой ошибкой и она быстро дойдет до самого верха

До верха она дойдёт с одинаковой скоростью

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

чтобы до верха доставить

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

Одинаковое

В одном случае throw, в другом raise

окей, сча

получается в конце концов у нас должен быть обработчик для Future[Either[Error, A]] который хендлит рековери по фьюче и хендлит все подтипы Error, так?

а если прилага многослойная и тебе нужно прокинуть реально с нижнего слоя ошибку до самого юзера

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

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

так так ведь делаешься в Future

у тебя есть чейн flatmap’ов

кто-то запаролся и у тебя оно пошло на верх до юзера

да, только так. третьего способа мне не известно. первый или второй сильно зависит от домена. можно сделать свой маленький EitherFlow[T], который будет скрывать всю сложность. можно все в рукопашную, что тоже ок

В общем что-то типа своего either-а сделал. И map через implicit class для flow этого типа

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

С удовольствием бы глянул код.

ты еще макро кэш попроси посмотреть =)

нифига себе, вы уже об этом второй день трете?)

кто-то запаролся и у тебя оно пошло на верх до юзера

в общем, ты вопрошаешь о различиях, за что ты платишь своей сложностью 1. код parseAppealForm[ F[_] : FunctorRaise[?, AppealFormError] :AppealStore](data: String) : F[AppealForm] убеждается в том, что ты вынужден как-то обработаь исключение в своём процессе а parseAppealForm(data: String, database: AppealDatabase) : Future[AppealForm] - нет 2. Первый код абстрагируется от асинхронности и конкретной реализации, а потому засовываем в обычные синхронные property-тесты и в другие проекты с твиттер фьючами, тасками всевозможными стримами, второй требует обёрток и адаптеров и асинхронных тестсьютов 3. Имея Future[A] в любом месте кода, ты не можешь определить обработал ли ты уже интересующий эксепшн, или нужно ещё раз написать рекавер, в случае ошибок в аннотации, ты всегда знаешь какой уровень фэйла ты можешь тащить в данном уровне 4. При масштабной архитектурке, тебе будет сложно найти все куски кода catch em all, чтобы быть уверенным, что твоя ошибка не словится в каком-то промежуточном слое и до конца дойдёт твой эксепшн. 5. Манатки ништяковые, эксепшоны - отстойные. Однако, это не значит, что нужно броситься переписывать всё. Можно для начала обеспечить возможность использования ерроров в типах и это самое сложное. Потом добавить еррор там, еррор сям и ты сам войдёшь во вкус

нифига себе, вы уже об этом второй день трете?)

Я вчера отказался тереть, а сегодня много времени в транспорте провёл

в общем, ты вопрошаешь о различиях, за что ты платишь своей сложностью 1. код parseAppealForm[ F[_] : FunctorRaise[?, AppealFormError] :AppealStore](data: String) : F[AppealForm] убеждается в том, что ты вынужден как-то обработаь исключение в своём процессе а parseAppealForm(data: String, database: AppealDatabase) : Future[AppealForm] - нет 2. Первый код абстрагируется от асинхронности и конкретной реализации, а потому засовываем в обычные синхронные property-тесты и в другие проекты с твиттер фьючами, тасками всевозможными стримами, второй требует обёрток и адаптеров и асинхронных тестсьютов 3. Имея Future[A] в любом месте кода, ты не можешь определить обработал ли ты уже интересующий эксепшн, или нужно ещё раз написать рекавер, в случае ошибок в аннотации, ты всегда знаешь какой уровень фэйла ты можешь тащить в данном уровне 4. При масштабной архитектурке, тебе будет сложно найти все куски кода catch em all, чтобы быть уверенным, что твоя ошибка не словится в каком-то промежуточном слое и до конца дойдёт твой эксепшн. 5. Манатки ништяковые, эксепшоны - отстойные. Однако, это не значит, что нужно броситься переписывать всё. Можно для начала обеспечить возможность использования ерроров в типах и это самое сложное. Потом добавить еррор там, еррор сям и ты сам войдёшь во вкус

плюсую за пятый пункт

я гляну чуть позже

спасибо

https://docs.scala-lang.org/sips/opaque-types.html

https://docs.scala-lang.org/sips/opaque-types.html

В Дотти же Phantom types будут.

В Дотти же Phantom types будут.

это другое

Фантом - это отдельная вселенная, а здесь нормальные ньютайпы наконец

Фантом - это отдельная вселенная, а здесь нормальные ньютайпы наконец

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

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

как - так же?

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

newtype Id = Long

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

Поэтому он сам по себе реален

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

А разве нельзя Scala Universe -> My Universe?

А разве нельзя Scala Universe -> My Universe?

Ну вот есть у тебя foo: Int => MyPhantom.Int и ты запускаешь foo(2), что ты ожидаешь?

фантомный тип - это идеальная кандидатура на роль тега, даже в ньютайпе в реализации Майлза или Михаила

Но сам по себе он не может иметь рантайм репрезентации

инстанс MyPhantom.Int - это нонсенс

Ну вот есть у тебя foo: Int => MyPhantom.Int и ты запускаешь foo(2), что ты ожидаешь?

Ну я как раз и ожидал тегнутый инт, ага. А newtype и теги сильно различаются? У меня что-то руки не дошли почитать.

Ну я как раз и ожидал тегнутый инт, ага. А newtype и теги сильно различаются? У меня что-то руки не дошли почитать.

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

Просто для меня Phantom types выглядят как более общий концепт, что ли.

Если говорить о тегах и ньютайпах в шейплез и супертаггед, то общая характеристика для них, если я правильно помню и Михаил сделал так же - A @@ Tag <:< A а для ньютайпа уже нет

Просто для меня Phantom types выглядят как более общий концепт, что ли.

это не связанный концепт

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

Т.е. никакой особо новой семантики фантомы не добавляют. Просто компилятор их раньше стирает и обращается попроще

Т.е. никакой особо новой семантики фантомы не добавляют. Просто компилятор их раньше стирает и обращается попроще

Ок. Вроде понял разницу. Спасибо!

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

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

Наверняка

Все типы, которые существуют просто для того, чтобы концы сошлись, хорошо засовываются в фантомы

Однако та реализация фантомов, что предложил Мартин, не предполагает расширение. Т.е. один раз разработчик библиотеки засовывает свой набор фантомов в свой обжект и с этим и живёшь. Вот это может и помешать

а может у кого-то есть под рукой поделие на шейплезе, которое из ADT а-ля фримонада вытаскивает множество значений? sealed trait Op[T] object Op { final case class Sum(i: Int, j: Int) extends Op[Long] final case class Div(i: Double, j: Double) extends Op[BigDecimal] } хочу Long :+: BigDecimal :+: Cnil

блин, кажется, нашел :( https://github.com/milessabin/shapeless/pull/561/files

Ну я как раз и ожидал тегнутый инт, ага. А newtype и теги сильно различаются? У меня что-то руки не дошли почитать.

https://gist.github.com/Rudogma/5f97030ab44d77e71354f025eac161bf ньютайпы конечно прикольны тем, что можно скрыть основание(и за счет этого можно переопределить любые операции которые были у основания) за слоем в компайлтайме (как будто ты сделал новый class Holder(value:Int) , но при этом это все таки не дополнительная обертка в рантайме) и для "уже обьектов" - это по сути ничего и не стоит, но примитивы боксируются в обьекты со всеми вытекающими

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

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

https://gist.github.com/Rudogma/5f97030ab44d77e71354f025eac161bf ньютайпы конечно прикольны тем, что можно скрыть основание(и за счет этого можно переопределить любые операции которые были у основания) за слоем в компайлтайме (как будто ты сделал новый class Holder(value:Int) , но при этом это все таки не дополнительная обертка в рантайме) и для "уже обьектов" - это по сути ничего и не стоит, но примитивы боксируются в обьекты со всеми вытекающими

Спасибо. Ну я как понял разницу между opaque и phantom - opaque для zero cost обёрток, phantom для каких-то type level вычислений.

Вот хаскеллисты, как выключить GC в жаве, так они обсуждать. А раз в полгода вопрос возник, так хрен кто

Вот хаскеллисты, как выключить GC в жаве, так они обсуждать. А раз в полгода вопрос возник, так хрен кто

они просто более токсик

Господа, я чего-то туплю. Есть Akka-http и мне очень хочется извлечь заголовки по шаблону. Такого напрямую нет, надо писать кастомную директиву. Ок, extractRequest.map(_.headers). К сожалению, на выходе Directive1[Tuple1[Seq[HttpHeaders]]]] В доке сказано: Directive1[Tuple1]] преобразуется в Directive1 имплиситами и они всегда со мной. Но не происходит. Может кто-нибудь рассказать мне, какой я не очень и как правильно? Спасибо.

Наверное, туплю в квадрате. В пятницу. Вечером. Спрашивать про работу.

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

tmap попробуй

Не точно, но лучше попробуй

провабол, не помогает. :)

Господа, я чего-то туплю. Есть Akka-http и мне очень хочется извлечь заголовки по шаблону. Такого напрямую нет, надо писать кастомную директиву. Ок, extractRequest.map(_.headers). К сожалению, на выходе Directive1[Tuple1[Seq[HttpHeaders]]]] В доке сказано: Directive1[Tuple1]] преобразуется в Directive1 имплиситами и они всегда со мной. Но не происходит. Может кто-нибудь рассказать мне, какой я не очень и как правильно? Спасибо.

extract(_.request.headers) так что ли?

не совсем понял чего ты хочешь добиться

extract(_.request.headers) так что ли?

это будет Route

да ладно

как этот шорткат называется чтобы показать тип выражения?

Shift-Ctrl-P у меня на маке (вроде не переопределял с дефолтного кейбинда)

Это разве не показать имплисит параметры?

Господа, я чего-то туплю. Есть Akka-http и мне очень хочется извлечь заголовки по шаблону. Такого напрямую нет, надо писать кастомную директиву. Ок, extractRequest.map(_.headers). К сожалению, на выходе Directive1[Tuple1[Seq[HttpHeaders]]]] В доке сказано: Directive1[Tuple1]] преобразуется в Directive1 имплиситами и они всегда со мной. Но не происходит. Может кто-нибудь рассказать мне, какой я не очень и как правильно? Спасибо.

кстати да, должны имплиситы работать

Господа, я чего-то туплю. Есть Akka-http и мне очень хочется извлечь заголовки по шаблону. Такого напрямую нет, надо писать кастомную директиву. Ок, extractRequest.map(_.headers). К сожалению, на выходе Directive1[Tuple1[Seq[HttpHeaders]]]] В доке сказано: Directive1[Tuple1]] преобразуется в Directive1 имплиситами и они всегда со мной. Но не происходит. Может кто-нибудь рассказать мне, какой я не очень и как правильно? Спасибо.

def foo: Directive1[immutable.Seq[HttpHeader]] = extractRequest.map(r => r.headers)

Это разве не показать имплисит параметры?

Shift+Cmd-P :)

def foo: Directive1[immutable.Seq[HttpHeader]] = extractRequest.map(r => r.headers)

В этом выражении у меня выводится тип с Tuple1, принудительное без тепла не компилится

А, на маке ctrl отдельно от cmd что ли

Что-то напортачил. Странно.

попробуй указать тип явно, без Tuple1

А, на маке ctrl отдельно от cmd что ли

Cmd это winbutton