AP
Окей) Но читаемости добавляет)
Только когда ты алиасишь что-то сложное. Вроде
type App cfg mode data = ...
type alias SimpleApp =
App SimpleConfig DebugMode ()
type App cfg mode data = ...
type alias SimpleApp =
App SimpleConfig DebugMode ()
Size: a a a
2019 June 26
DK
По алиасам стало понятнее, а вот про обёртки, что имеется ввиду?
AP
вот обёртка для строки
AP
type Error = Error String
AP
Это новый тип, но изоморфный строке (множество значений совпадает с множеством значений типа "строка")
DK
Всё, дошло) Спасибо!)
Это хорошо, но почему когда в моём примере в полях одинаковые значения, то мы всё еще видим ошибку?)
Это хорошо, но почему когда в моём примере в полях одинаковые значения, то мы всё еще видим ошибку?)
RT
Кстати кто как у себя организовывает типы вроде такой ошибки error string. Отдельный файл на каждый подобный тип и внутри map и какой нибудь unwrap/toString ? Или всю подобную мелочь в кучу и назывете unwrapError/unwrapFirstName/...
2019 June 27
AP
unwrap не нужен
AP
Pattern Matching ибо. Достаточно экспортировать конструктор обёртки
AP
А в случае чего и пайпнуть через
(\(NameError s) -> s) не страшноAP
минус одна функция, которой нужно имя придумывать :)
AP
Если все ошибки фнутри строковые, то можно саму обёртку потэгать, тогда часть поведения можно будет обобщить
AP
Но такие ошибки уже могут смешиваться, т.е. снаружи это один тип.
AP
Зато если параметризовать фантомным типом, то будет и безопасность в плане несмешивания, и часть кода можно будет обобщить: https://ellie-app.com/5VYvStm53f4a1
AP
https://ellie-app.com/5VYxW6846yca1 вот тут обобщена функция для извлечения текста из типа ошибки
AP
Можно даже между ошибками конвертирсию сделать
convert : tag1 -> tag2 -> Error tag1 -> Error tag2
convert _ _ (Error s) = Error s
convert Foo Bar <| error Foo "foo"RT
Ага, я это понимаю. Просто поинтересовался все ли примерно так и делают.
AP
Вполне обычная практика