страница старая, свежее глянь

Это про конверсию типов

из отличий только что метод прибит к структуре

Этим никто не пользуется

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

https://msdn.microsoft.com/en-us/library/zk2z37d3.aspx

Эта ваша неявная конверсия типов

но тоже не сильно сложнее

Ну я про то, что в С# это не очень принято

Можно написать

Но это сложно поддерживать потом

Т.е. по факту это маппинг типов

Посему возникает соблазн писать в таком стиле маппинг dto->entity, например

И тут уже сам черт ногу сломит при более-менее больших объемах кода

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

Не пойму, почему загадочно? Контекст имплиситно не передался для создания провайдера и создался по умолчанию. Даже в сорцы не надо лезть, чтобы причинно-следственную связь установить.

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

Так с точки зрения компилятора там все норм.

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

очевидно хорошее их применение - type classes

вся scalaz на этом сделана

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

> @lolepezy а вот за пихание имплиситов куда не попадя просто для синтаксических упрощений надо бить по рукам Истово плюсую

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

+1 и опять доказали что кривые ручки всему виной, что написал то и получил, проблема не в языке и не в его фичах, везде надо подходить с умом.

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

все популярные json библиотеки на scala построены на этих самых тайпклассах. и это оправданно, думаю тут многие согласны. но я думаю что у многих бывали проблемы: 1. Так, какого имплисита тут не хватает, раз оно все не компилится 2. Ой, почему он сериализовался так, а не как я хотел? Хм, похоже где-то используются дефолтные derived энкодеры, а не те что я хочу. А! так я же забыл импорт поставить второй случай в рантайме обнаруживается.

Парни, что вы спорите . Больше всего способов отстрелисть себе ногу все же в с++

первый способ - это выбрать с ++?

Ну типа того, да

в идрисе есть имплиситы

даже в Haskell есть имплиситы

все популярные json библиотеки на scala построены на этих самых тайпклассах. и это оправданно, думаю тут многие согласны. но я думаю что у многих бывали проблемы: 1. Так, какого имплисита тут не хватает, раз оно все не компилится 2. Ой, почему он сериализовался так, а не как я хотел? Хм, похоже где-то используются дефолтные derived энкодеры, а не те что я хочу. А! так я же забыл импорт поставить второй случай в рантайме обнаруживается.

обнаруживается в рантайме и решается тестами, кто не пишет, сам виноват)

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

обнаруживается в рантайме и решается тестами, кто не пишет, сам виноват)

ахаххаххаа

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

ахаххаххаа

ахаххаххаа

ахаххаххаа

аххххаххахахах

ахаххаххаа

ахаххаххаа

Нунафиг такое поведение

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

нет, не может

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

нет, не может

нет, может

обнаруживается в рантайме и решается тестами, кто не пишет, сам виноват)

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

нет, может

не не может. Во всех эти библиотеках тебе нужно либо намеренно написать deriveCircusDog для каждого кейз-класса. Либо у тебя будет ambiguity для внутреннего типа. Т.е. тебе нужно не просто найти такой волшебный import который введёт в скоуп все нужные CircusDog[_] для всех нужных типов, но ещё и убрать нужные

Ну т.е. если честно

0 раз такое случалось с кем угодно

Это просто бабушкины пугалки про имплиситы

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

я понимаю, если у тебя implicit Long в библиотеке использвется, но мы-то про развитую систему generic deriving говорим

ну черт, да тот же самый Either в circe сереализуется как { "foo" : { "a" : 1 } }

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

очень просто ошибиться

вот сейчас мне скажут "сам дурак, не стреляй себе в ногу, нормально делай - нормально будет"

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

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

но тоже самое в pro.jvm чате говорят про какую-то дичь, которую в scala ловим на этапе компиляции

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

Мне не приходилось ) К счастью

импортни generic.auto._

или generic.semiauto._

и вообще, давай в scalafiddle

как же херово-то ааа, надо же поставил дискриминатор

говённый сирс

А самое главное, что это в сто раз лучше, чем reflection-based говно вроде json4s, где вот реально фиг найдёшь, что будет в итоге юзаться для сериализации

да json4s вообще с пониженой социальной ответственностью

Уродливый джесончик сирка генерит. То ли дело пушка scala> write(Right(2): Either[String, Int]) res4: String = {"right":2}

ERROR: S client not available

каждый раз проигрываю, когда слышу про этот фреймворк

все решается настройкой принтера

это просто пушка

все решается настройкой принтера

Тут дело не в принтере, а то какой ast генерится.

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

что пушка что серси

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

А как должно быть?

врядли потребиль json'а будет рад получить Either

ну скажем так если это общение между двумя серверами где автоматически выводтся декодеры энкодеры - пофиг вообще

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

врядли потребиль json'а будет рад получить Either

+1

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

Это ок. Я говорю про вот этот value. Кирка и для адт то же самое сгенерит ведь, так?

Ну в смысле sealed trait Foo case class A(x: Int) extends Foo case class B(x: String) extends Foo case class C(x: Boolean) extends Foo A(10).asJson // { "A": { "value": 10 } }

ну скажем так если это общение между двумя серверами где автоматически выводтся декодеры энкодеры - пофиг вообще

а вот кстати. Кто знает (и пользовался) хорошими RPC для скалы? Я знаю про remotely, но под него надо весь проект перелопачивать и akka-rpc есть вроде, но он какой-то не очень зрелый. Потому что гонять json между серверами как-то тупо и надоело.

gRPC смотри Например etcd с третьей версии тоже на нем

Главное есть имлементация под Go

а вот кстати. Кто знает (и пользовался) хорошими RPC для скалы? Я знаю про remotely, но под него надо весь проект перелопачивать и akka-rpc есть вроде, но он какой-то не очень зрелый. Потому что гонять json между серверами как-то тупо и надоело.

а у тебя акка?

Ну в смысле sealed trait Foo case class A(x: Int) extends Foo case class B(x: String) extends Foo case class C(x: Boolean) extends Foo A(10).asJson // { "A": { "value": 10 } }

кстати нет, там будет "A": {x: 10}

а у тебя акка?

нет, у меня полдюжины сервисов на джаве и скале, и также полдюжины программистов, которые считают, что rest api - это вершина программистской мысли, поэтому половина девелоперского времени уходит на парсинги и сериализации jsona. И вот их всех хотелось бы убедить, что на это можно не тратить время. То есть все сложнее, короче.

понятно. Но, к слову, REST все-таки не так плох. В HTTP уже кеширование продумано и все-все-все. А еще HTTP тестить ну очень просто и удобно, есть удобная питоновская приложуха для этого (названия уже не припомню). Другое дело, если у тебя реально много данных гоняется между сервисами

конечно неплох

прост и понятен и легко дебажить

но можно и лучше сделать

ну во всяком случае мне так кажется

а они в рукопашную чтоли парсят?

нет, зачем json4s или что-то там спринговое

просто это дурацкая работа, которую за тебя может делать фреймворк

но можно и лучше сделать

Эх, видимо по такой логике и действуют node-программисты, судя по тому что у них на каждую простейшую задачу существует по 100500 разных пакетов))

Ну в смысле sealed trait Foo case class A(x: Int) extends Foo case class B(x: String) extends Foo case class C(x: Boolean) extends Foo A(10).asJson // { "A": { "value": 10 } }

да, но это можно настроить

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