забыл никandreykaTя к тому что ты можешь что то переписать или переопределить чтоб это стало опциональным требованием.
Ну можешь да, software меняется, это естественно, так в чем собственно вопрос?
andreykaTа так имхо это вообще шаг назад. ты и в джаве мог написать метод типа файндолл или что угодно еще где обязательно надо передать объект типа какой нить транзакшн менеджер. и типа опа видишь теперь точно не забудешь. ога.
Так и надо делать. А потом появляется куча джунов, которые ни черта не понимают как это работает и ответы на стекфоверфлоу становятся похожи на - ну попробуй добавить аннотацию @Whatever. супер. Правда тут четко надо различать bl-compexity и infrastrcture-complexity. Управление транзакциями - это часть бизнес-логики, хочешь ты этого или нет. Делая ее неявной ты ступаешь на очень скользкую дорожку.
andreykaTи вот чтоб от этого бойлерплейта уйти придумали декларативный (декоративный? :)) способ с аннотацией. а то что сверху имхо это какой-то прошлый век. добро пожаловать в средневековье.
Все ошибаются, раньше я тоже думал что это круто. Любая runtime-аннотация это нетипизированная хрень, которую ни продеюажишь ни пофиксишь, зачем тебе java тогда вообще? Не для сильной типизации ли? А от бойлерплейта уйти можно многими способами, ты сам прекрасно знаешь насколько мощные implicits в scala. Вот тебе кусок логики, полностью обернутый в IO, но ты об этом врядли догадаешься просто посмотрев на код. (Тем не менее код абсолютно без сайд-эффектов)
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
override def run(cache:TRef[Cache], network:NetworkService): ZIO[AppEnv, Throwable, List[Profile]] = for {
_ <- logger.infoIO(s"Start loop execution")
userList <- network.loadUserList
countOfPages <- Parser.countPages(userList)
pages <- fetchPages(countOfPages)
userNames <- mapToUserNames(pages)
inactiveUsers <- getInactiveUsers
profiles <- fetchAllProfiles(userNames, inactiveUsers, cache)
_ <- logger.infoIO(s"Elapsed time: $sec s")
} yield profiles
у имплиситов другая беда (опять же на мой взгляд я не профи-скала и думаю что юзаю ее на 10% от возможностей), у них беда в том что оно где то как то может навеситься-переопределиться а ты и знать не будешь что за чухня происходит и почему. хорошо если ИДЕ подсветит. а если нет ну будешь клики нарезать. особенно если код незнакомый.
насчет декораторов (мне кажется, это более верное название, практикуемое в ноде и несте) помню был движ несколько лет назад в сторону аспектно-ориентированного программирования. типа вот СОЛИД вот буква О вот АОП - это ж прям вот то что надо давайте расширять функционал без изменения базового кода. давайте вешать на него аспекты и аспекты на аспекты а потом еще аспекты. и опа. чо за фигня чо за макароны я вашу душу почему это тут происходит. )) вроде потом отъехали. и смотрю в новых фреймворках успешно идею похерили. а в старых рекомендуют юзать только для мониторинга и логирования. угу.
так и с имплиситами. пока это забавно. а дальше - time will say
