Size: a a a

Scala User Group

2020 September 23

AD

Apache DOG™ in Scala User Group
Oleg ℕizhnik
Можно затащить в тофу оптики под шумок
Зачем оптики если есть геттеры и копи, а для продирания сквозь структуры есть куча методов?
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Apache DOG™
Зачем оптики если есть геттеры и копи, а для продирания сквозь структуры есть куча методов?
зачем оптики, или зачем линзы?
источник

λ

λoλdog in Scala User Group
Apache DOG™
Зачем оптики если есть геттеры и копи, а для продирания сквозь структуры есть куча методов?
Чтобы не писать копи миллион раз
источник

AD

Apache DOG™ in Scala User Group
Oleg ℕizhnik
зачем оптики, или зачем линзы?
Зачем нужны линзы-призмы вообще я знаю, какая непосредственная польза от них в цкале, ведь они и так прекрасно пишутся, только неявно.
источник

λ

λoλdog in Scala User Group
Что значит неявно?
источник

AT

Aλeksei Tereχin in Scala User Group
λoλdog
Что значит неявно?
ну когда пишешь прозрачными чернилами видимо
источник

Oℕ

Oleg ℕizhnik in Scala User Group
ну есть же мотивация на сайте монокля
источник

Oℕ

Oleg ℕizhnik in Scala User Group
источник

Oℕ

Oleg ℕizhnik in Scala User Group
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Но я даже про линзы я бы иначе выразился
источник

P

Pavel in Scala User Group
с помощью оптик можно еще избегать всякие кастинги в коде
источник

AD

Apache DOG™ in Scala User Group
Oleg ℕizhnik
ну есть же мотивация на сайте монокля
Недостаточная
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Apache DOG™
Недостаточная
Ну не используй
источник

P

Pavel in Scala User Group
Apache DOG™
Недостаточная
так в целом про любую фичу можно сказать и писать на го
источник

AD

Apache DOG™ in Scala User Group
Oleg ℕizhnik
Ну не используй
И так
источник

λ

λoλdog in Scala User Group
Apache DOG™
Недостаточная
Серьезно?
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Oleg ℕizhnik
Но я даже про линзы я бы иначе выразился
К примеру если у вас было
case class Person(adress : Address)

а стало

case class Person( data: PersonalData)
case class PersonalData( address: Address)

такой классический рефакторинг

Если у вас мутабельная ,за счёт сеттеров у вас есть некоторая robustness. У вас был просто
void setAddress  ну или def address_=

и во второй версии вы его имплементировали как
this.personalData.setAddress, а с иммутабельными без линз нужно переписывать все места использования

получается внезапно, что мутабельная версия имеет большую устойчивость к рефакторингу и гибкость, чем иммутабельная, т.е. ломается один из главных пойнтов ФП

а с линзами у вас как был

adress: Lens[Person, Address]

так и остался

этого пойнта мне уже обычно достаточно конкретно для мономорфных линз
источник

AD

Apache DOG™ in Scala User Group
Oleg ℕizhnik
К примеру если у вас было
case class Person(adress : Address)

а стало

case class Person( data: PersonalData)
case class PersonalData( address: Address)

такой классический рефакторинг

Если у вас мутабельная ,за счёт сеттеров у вас есть некоторая robustness. У вас был просто
void setAddress  ну или def address_=

и во второй версии вы его имплементировали как
this.personalData.setAddress, а с иммутабельными без линз нужно переписывать все места использования

получается внезапно, что мутабельная версия имеет большую устойчивость к рефакторингу и гибкость, чем иммутабельная, т.е. ломается один из главных пойнтов ФП

а с линзами у вас как был

adress: Lens[Person, Address]

так и остался

этого пойнта мне уже обычно достаточно конкретно для мономорфных линз
Никогда на эти грабли не наступал, всегда использую через копи  и именованные аргументы когда надо что то изменить
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Можно конечно заставлять кодеров писать руками
withAddress

на каждое поле в каждой структуре
Но зачем, если есть просто аннотташка.
источник

Oℕ

Oleg ℕizhnik in Scala User Group
Apache DOG™
Никогда на эти грабли не наступал, всегда использую через копи  и именованные аргументы когда надо что то изменить
Это не грабли, это рефакторинг
источник