SP
или завернуть в монаду Result
Size: a a a
2020 April 29
IM
Да там один хер у тебя будет тупл, обёрнутый в резалт
IM
или хеш, обернутый в резалт. Принцип не изменится
DM
хеши неповоротливы, классы на замену им не всегда уместны
когда влом делать целый класс для двух значений, можно взять OpenStruct
S
Меня в целом такая запись вполне устраивает
но вот коллега говорит, что в этом случае логичнее использовать просто class
т.к. ели подразумевается что есть несколько значений, значит есть состояние и методы (т.е. класс знает как рендерится темплейт).
но вот коллега говорит, что в этом случае логичнее использовать просто class
т.к. ели подразумевается что есть несколько значений, значит есть состояние и методы (т.е. класс знает как рендерится темплейт).
SP
вроде не тупл/хеш, а Struct
SP
когда влом делать целый класс для двух значений, можно взять OpenStruct
OpenStruct медленный
IM
когда влом делать целый класс для двух значений, можно взять OpenStruct
ради такого использовать опенстракт это как-то вообще
IM
в языке дали волшебную вещь — массив, который легко деструктуризовать
NB
можно посмотреть в сторону https://dry-rb.org/gems/dry-struct/1.0/
IM
на туплах из 1, 2 и 3 элементов не нужно угорать и давать им имена. это всё нормально коммуницируется и без этого
NB
но в большинстве случаев обычного массива как правило действительно хватает
IM
вроде не тупл/хеш, а Struct
ну если человек хочет вернуть
template, context, filename, то в Success будет Success([template, context, filename]). Что, в общем-то, просто добавляет лишнюю обёрткуIM
это, кстати, интересное явление. в эликсире тьюплы повсюду, а в рубях почему-то не очень
IM
причём есть абсолютно всё, чтобы с ними нормально работать
IM
делаю ставку, что с развитием паттерн-матчинга мы будем о тьюплах слышать чаще
S
Меня в целом такая запись вполне устраивает
но вот коллега говорит, что в этом случае логичнее использовать просто class
т.к. ели подразумевается что есть несколько значений, значит есть состояние и методы (т.е. класс знает как рендерится темплейт).
но вот коллега говорит, что в этом случае логичнее использовать просто class
т.к. ели подразумевается что есть несколько значений, значит есть состояние и методы (т.е. класс знает как рендерится темплейт).
это аргумент? или можно парировать тем, что у меня сервис-объект отвечает/выполняет одно единственное логическое дейстие, просто возвращает несколько значений?)
IM
если хочется засунуть результат внутрь самого класса сервиса, то не надо. это вредно
IM
можно на самом деле сделать отдельную структурку/DTO и возвращать её, если людям удобнее в этой парадигме жить.
но это на фундаментальном уровне ничем не отличается от массива из N элементов
но это на фундаментальном уровне ничем не отличается от массива из N элементов
IM
желание запихнуть результат выполнения какой-то операции в стейт самой операции исходит из того, что людей просто неправильно научили