ΛВ
Из кетс
Size: a a a
2021 June 04
a
я проболвал с Sync
a
не работает
a
точнее мне изначально надо было
Sync[F]a
потому что оно в конечном итоге приходит к тому что метод идёт из синтаксиса
MonadErrora
я в скасти сделал пример на кастомных типах
a
https://youtrack.jetbrains.com/issue/SCL-19124
поплюсуйте багтикет кому такой баг встречался
поплюсуйте багтикет кому такой баг встречался
T
помогите решить доктринальный конфликт
есть мнение что case class это и есть модель в смысле данные + трансформации, поэтому в него пихают много разных трансформационных методов (не withXXX которые типа factory, а которые типа линз)
и есть мнение что первое мнение это объектно-ориентированная ересь, что case class должен быть pure ADT, а все трансформации должны быть функциями в companion object или вообще отдельно, в трейте ZZZOps
есть третье мнение что первые два мнения это вкусовщина
есть мнение что case class это и есть модель в смысле данные + трансформации, поэтому в него пихают много разных трансформационных методов (не withXXX которые типа factory, а которые типа линз)
и есть мнение что первое мнение это объектно-ориентированная ересь, что case class должен быть pure ADT, а все трансформации должны быть функциями в companion object или вообще отдельно, в трейте ZZZOps
есть третье мнение что первые два мнения это вкусовщина
P
есть мнение, что второе мнение религиозное, а не практическое.
при этом, если говорить о линзах - они же будут в компаньоне
3 как по мне, главное что бы было везде одинаково, а не где-то так, а где-то так. мы вот довольно жестко на оптиках сидим.
при этом, если говорить о линзах - они же будут в компаньоне
3 как по мне, главное что бы было везде одинаково, а не где-то так, а где-то так. мы вот довольно жестко на оптиках сидим.
M
pure практичнее. вычислимые доп.поля - не мешают, а вот методы-расширения очень даже мешаются в основном теле
T
в пользу второго - иногда в трансформациях может быть что-то, не атрибут case class (то есть его например не надо сериализовать), но атрибут именно трансформации
типа clock, который в unit test хорошо уметь встроить отдельно
типа clock, который в unit test хорошо уметь встроить отдельно
P
мне кажется в скале 3 таких дискуссий будет меньше и удобнее использовать extension методы
EK
ООП-ересь - это считать, что эти методы - неотъемлимая часть этого класса и строить из этого политическую программу.
Если же хочется добавить методы просто потому что вызов через точку приятнее - почему нет. Просто нужно не стесняться эти методы выносить наружу, если в будущем окажется, что они мешают
Если же хочется добавить методы просто потому что вызов через точку приятнее - почему нет. Просто нужно не стесняться эти методы выносить наружу, если в будущем окажется, что они мешают
EK
Короче, чем спорить об этом, лучше бы акку удалили
Oℕ
Oℕ
метод кейс класса это же просто функция на кейсклассе, которую удобно найти и приятно применять
Oℕ
как и для любого иммутабельного типа
VS
Есть ли тут знатоки circe?