В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Scala User Group

2140 membersпожаловаться на группу
2020 November 30

VS

Vladimir Sapronov in Scala User Group
Kirill Shelopugin
В скасти Михаила всё хорошо, кроме того, что есть аллокация декодера каждый раз. Стандартным подходом для избавления от этого является трейт, от которого ты свой энум будешь наследовать и там будет инстанс тайпкласса один раз аллоцироваться.
Вот пример с двумя энумами. К каждому энуму просто достаточно будет добавлять with StringTheReader[<новый энум>] и получишь инстанс своего тайпкласса.
https://scastie.scala-lang.org/jhbaqic2SuqhMhRC84el6A
Scastie
Scastie - An interactive playground for Scala.
Scastie can run any Scala program with any library in your browser. You don’t need to download or install anything.
Но смотри, интуитивно - это плохо. Чтобы сделать какой-то тип сериализуемым, ты должен залезть в его определение.
источник
21:54пожаловаться#1

VS

Vladimir Sapronov in Scala User Group
Как бэ тогда и скала не нужна. Определяем toString fromString на каждом типе.....
источник
21:54пожаловаться#2

KS

Kirill Shelopugin in Scala User Group
А чем это плохо? Инстанс тайпкласса класть для discoverability в компаньон - стандартная практика. У тебя есть тип данных и сразу рядом с ним инстансы для него
источник
21:55пожаловаться#3

KS

Kirill Shelopugin in Scala User Group
Как минимум, у тебя инстансы в одном месте и не разбросаны по кодовой базе. Плюсом получаешь отсутствие необходимости импорты писать
источник
21:55пожаловаться#4

VS

Vladimir Sapronov in Scala User Group
Kirill Shelopugin
А чем это плохо? Инстанс тайпкласса класть для discoverability в компаньон - стандартная практика. У тебя есть тип данных и сразу рядом с ним инстансы для него
Нарушается ортогональность. Типы - это отражение какой-то там (бизнесс)логики, а их сериализуемость - чисто техническая лабуда для семантики кода не важная. Это две ортогональные вещи друг другу, но вдруг начали влиять друг на друга. Хотя и компилятор за этим присматривает (что есть конечно же плюс).
источник
21:57пожаловаться#5

KS

Kirill Shelopugin in Scala User Group
Мне такая логика не очень понятна. Где-то какие-то правила в камне высечены? Почему наличие инстансов к типу данных влияет на определение самих данных? Не влияет. От того, что ты поместишь в компаньон что-то, определение самого типа данных не изменится.
источник
21:58пожаловаться#6

AD

Apache DOG™ in Scala User Group
Vladimir Sapronov
Нарушается ортогональность. Типы - это отражение какой-то там (бизнесс)логики, а их сериализуемость - чисто техническая лабуда для семантики кода не важная. Это две ортогональные вещи друг другу, но вдруг начали влиять друг на друга. Хотя и компилятор за этим присматривает (что есть конечно же плюс).
Далеко не всегда не важная. Если вы продаете условный json rest, то сериализация это бизнес логика
источник
21:59пожаловаться#7

KS

Kirill Shelopugin in Scala User Group
Напротив, ты описываешь тип данных и сразу рядом с ним описываешь: как его можно превратить в JSON, как распарсить из HTTP-хедера, как положить в БД. И сразу эти инстансы автоматически цепляются. Лежат рядом, их удобно находить. Если не нравится или нужно переопределить локально - пожалуйста, локально они переопределяемы спокойно
источник
22:00пожаловаться#8

М

Михаил in Scala User Group
Vladimir Sapronov
Но смотри, интуитивно - это плохо. Чтобы сделать какой-то тип сериализуемым, ты должен залезть в его определение.
Ты же не «залезаешь» в определение типа с таким паттерном. От CirceEnum наследуется не сам тип, а его объект-компаньон
источник
22:01пожаловаться#9

M

Mikhail in Scala User Group
Vladimir Sapronov
Но смотри, интуитивно - это плохо. Чтобы сделать какой-то тип сериализуемым, ты должен залезть в его определение.
Твои рассуждения не лишены логики. Есть разные подходы, есть разные случаи, где-то их применение пересекается, где-то предпочтительнее конкретный вариант.  Это норм
источник
22:02пожаловаться#10

M

Mikhail in Scala User Group
Mikhail
Твои рассуждения не лишены логики. Есть разные подходы, есть разные случаи, где-то их применение пересекается, где-то предпочтительнее конкретный вариант.  Это норм
Главное понимать последствия того или иного выбора, тогда и вопросы как обычно - отпадут сами.
источник
22:03пожаловаться#11

М

Михаил in Scala User Group
Ну и это не обязательная, а рекомендуемая практика для тех случаев, когда у тебя есть доступ к компаньону. Если пишешь инстансы для типа из какой-то библиотеки, то их в любом случае придётся положить «сбоку»
источник
22:03пожаловаться#12

VS

Vladimir Sapronov in Scala User Group
Ну как-то сами варианты енама - это все-таки определние логики. Нельзя вот так вот сказать что trait отдельно, companion object  отдельно. Чисто в бизнесс-требованиях даже будет: принимает 3 различных значение. Ну ты пошел и в коде записал: один, два, три. И не забудть пометить, что они сериализуемы.... А при чем тут сериализация - хрен знает.
источник
22:04пожаловаться#13

KS

Kirill Shelopugin in Scala User Group
Философия самоотпадающих вопросов by @rudogma :D
источник
22:04пожаловаться#14

VS

Vladimir Sapronov in Scala User Group
Михаил
Ну и это не обязательная, а рекомендуемая практика для тех случаев, когда у тебя есть доступ к компаньону. Если пишешь инстансы для типа из какой-то библиотеки, то их в любом случае придётся положить «сбоку»
тут просто на сколько я понимаю отвязать в скале нельзя - где-то создать конкретный декодер придется чтобы не создавать его на каждый чих
источник
22:05пожаловаться#15

VS

Vladimir Sapronov in Scala User Group
это не вопрос выбора - потому что выбора нет
источник
22:05пожаловаться#16

KS

Kirill Shelopugin in Scala User Group
Vladimir Sapronov
Ну как-то сами варианты енама - это все-таки определние логики. Нельзя вот так вот сказать что trait отдельно, companion object  отдельно. Чисто в бизнесс-требованиях даже будет: принимает 3 различных значение. Ну ты пошел и в коде записал: один, два, три. И не забудть пометить, что они сериализуемы.... А при чем тут сериализация - хрен знает.
Выше правильно написали - нет истинно верных или неверных правил. Делай так, как тебе, твоим коллегам удобнее, более читаемо, как вам будет потом удобнее поддерживать. Просто подход, который мы описали и который используется в библиотеках - один из распространенных.
источник
22:05пожаловаться#17

λ

λoλegΥch in Scala User Group
Vladimir Sapronov
тут просто на сколько я понимаю отвязать в скале нельзя - где-то создать конкретный декодер придется чтобы не создавать его на каждый чих
гугли typeclass coherence и new types
источник
22:06пожаловаться#18

М

Михаил in Scala User Group
Vladimir Sapronov
это не вопрос выбора - потому что выбора нет
ну вот Михаил написал в скасти пример с альтернативным подходом, он компилируется и работает
источник
22:06пожаловаться#19

M

Mikhail in Scala User Group
Kirill Shelopugin
Философия самоотпадающих вопросов by @rudogma :D
I'm eating my own dog food every day 😝
источник
22:06пожаловаться#20