AK
так как пока это нереально, справляемся как можем
Size: a a a
2019 June 27
AP
Вроде была либа, которая позволяла таскать вместе со словарём функцию "внешний ключ -> внутренний ключ". Тем самым можно было получить словари с произвольными типами ключей. Можно подумать, вдруг такое прокатит
AK
было что-то в explorations
AP
А так неплохо хотя-бы для деконструкции иметь функцию
Cart -> { selected, dict }, которая просто разберёт на составляющие. Не получится сделать настоящий Pattern Matching, но хоть что-тоAP
Такая деконструкция лучше, чем ворох геттеров
AK
хм, может быть
AK
пока не была нужды
AK
но буду иметь ввиду
AP
В своём коде обычно всё рядом. Но печально, когда такое делают в либах — автор либы не всегда может представить все кейсы, которые может захотеть пользователь
AP
Скажем, есть у меня
Я хочу скрыть конструктор и давать создавать цвета через
Так вот лучше иметь
type RGB = RGB Float Float Floatи каждый
Float должен быть в диапазоне 0.0..1.0.Я хочу скрыть конструктор и давать создавать цвета через
rgb :: Float -> Float -> Float -> Maybe RGBТак вот лучше иметь
unRGB -> RGB -> { red : Float, green : Float, blue : Float }
чем отдельныеrgbRed : RGB -> Float
rgbBlue ...AP
Потому что отдельный геттер отлично композится через
.red << unRGB, а если геттера три, то собирать во что-то большое будет уже неудобно. И за раз все компоненты не сматчишь.AP
(правда рекорды в Elm всё равно нельзя матчить...)
AK
вы небось фанат Эликсира?
AP
Я-то (лучше на "ты")? Не, я хаскелист же
AP
В хаскеле можно кстомные ключи иметь в словариках :)
AP
А Эликсир слишком динамически типизирован для меня. Я статику люблю
AK
понятненько
RT
Алексей, ну вот в таком примере с rgb ты как создатель либы потенциальной выставишь наружу rgb конструктор?
AP
Я бы выставил. Потому что тип всё равно слабый, и на потребляющей стороне надо бы проверять.
RT
Ну по мне скользкий вопрос. Наверно единого мнения тут не будет. Просто риски оценивать как то субъективно.