SA
сумбур какой-то. мы же про раздельные модели начали говорить? для них никакой рефлекшн не обязателен.
Size: a a a
2020 February 05
SA
далее, если рефлекшн используется для чтения метаданных из аннотаций и создания объектов, например, в парсере json/xml, что в этом принципиально плохого? тебе, как пользователю, не пофиг, собирается это в компайл-тайм или в рантайме, пока это работает быстро и хорошо?
λ
нет конешно, но из-за рефлекшена других решений старые жее-консультанты не видят
SA
тут такое дело - новые решения не должны уступать старым по качеству, ну или хотя бы иметь другие преимущества. возвращаясь к началу, использование refined для валидации модели апи (dto - data transfer object) может означать либо мартышкин труд, если refined используется только в dto, либо излишнюю связность, если refined типы из dto используются по всему приложению.
SA
новые подходы, как и новые языки, вовсе не отменяют принципов построения приложений, накопленных джавистами за много лет. в скала-сообществе раньше было принято всё это игнорировать, да и сейчас пытаются)
Пример: не так давно все тащили за ФП, только функции и тайпклассы, только хардкор, трейты не нужны, классы не нужны (кроме ADT). И чем кончилось?)
Пример: не так давно все тащили за ФП, только функции и тайпклассы, только хардкор, трейты не нужны, классы не нужны (кроме ADT). И чем кончилось?)
VG
Кончилось все наследованием
λ
отменяют
λ
новые подходы, как и новые языки, вовсе не отменяют принципов построения приложений, накопленных джавистами за много лет. в скала-сообществе раньше было принято всё это игнорировать, да и сейчас пытаются)
Пример: не так давно все тащили за ФП, только функции и тайпклассы, только хардкор, трейты не нужны, классы не нужны (кроме ADT). И чем кончилось?)
Пример: не так давно все тащили за ФП, только функции и тайпклассы, только хардкор, трейты не нужны, классы не нужны (кроме ADT). И чем кончилось?)
вот это неправда
K
новые подходы, как и новые языки, вовсе не отменяют принципов построения приложений, накопленных джавистами за много лет. в скала-сообществе раньше было принято всё это игнорировать, да и сейчас пытаются)
Пример: не так давно все тащили за ФП, только функции и тайпклассы, только хардкор, трейты не нужны, классы не нужны (кроме ADT). И чем кончилось?)
Пример: не так давно все тащили за ФП, только функции и тайпклассы, только хардкор, трейты не нужны, классы не нужны (кроме ADT). И чем кончилось?)
и геттеры с сеттерами это проверенное
K
новые подходы, как и новые языки, вовсе не отменяют принципов построения приложений, накопленных джавистами за много лет. в скала-сообществе раньше было принято всё это игнорировать, да и сейчас пытаются)
Пример: не так давно все тащили за ФП, только функции и тайпклассы, только хардкор, трейты не нужны, классы не нужны (кроме ADT). И чем кончилось?)
Пример: не так давно все тащили за ФП, только функции и тайпклассы, только хардкор, трейты не нужны, классы не нужны (кроме ADT). И чем кончилось?)
так игнорируют или нет?
λ
жее вдолбило людям в голову что есть три уровня, с разными форматами сериализации, а поскольку сериализация чисто рефлекшеном делается то нужно разные модели
λ
а если посреди уровня нужна какаято реификация - не это бойлерплейт
λ
чисто явовские штуки про которые нужно забыть
Oℕ
новые подходы, как и новые языки, вовсе не отменяют принципов построения приложений, накопленных джавистами за много лет. в скала-сообществе раньше было принято всё это игнорировать, да и сейчас пытаются)
Пример: не так давно все тащили за ФП, только функции и тайпклассы, только хардкор, трейты не нужны, классы не нужны (кроме ADT). И чем кончилось?)
Пример: не так давно все тащили за ФП, только функции и тайпклассы, только хардкор, трейты не нужны, классы не нужны (кроме ADT). И чем кончилось?)
не могли бы вы скинуть линк на кого-нибудь из "всех", утверждавших, что трейты не нужны
Учитывая, что трейты - это модули, они всегда были фундаментальной частью скалового ФП.
Учитывая, что трейты - это модули, они всегда были фундаментальной частью скалового ФП.
Oℕ
Тайпклассы в скала - это трейты
Oℕ
Ну и ООП - это конечно же более новое решение, чем ФП, даже если сравнивать ООП с паттернами и ФП с тайпклассами
Oℕ
И да, оно и правда, уступало по качеству и, к несчастью, не было вовремя отброшено в этой связи, согласен, что зря
VS
Мне ночная тема про refined UUIID напомнила одну вещь, почему в java такой тупой UUID ? https://scastie.scala-lang.org/valery-shinkevich/nyBJhTJHRlaAB8PFyOl3DQ/3
DM
Мне ночная тема про refined UUIID напомнила одну вещь, почему в java такой тупой UUID ? https://scastie.scala-lang.org/valery-shinkevich/nyBJhTJHRlaAB8PFyOl3DQ/3
возможно это не он тупой https://tools.ietf.org/html/rfc4122#section-3
VS
возможно это не он тупой https://tools.ietf.org/html/rfc4122#section-3
не спорю, всё по RFC... но, блин, могли бы, за столько-то лет и добавить :)