Т8
Слушай, а и правда хорошо выглядит
HKT по-прежнему не нужны, как я понимаю?
Size: a a a
2020 March 12
DS
Т-34 85
HKT по-прежнему не нужны, как я понимаю?
HKT - это то, что позволяет переиспользовать код в большей мере, чем без него возможно.
DS
Я уже приводил пример выше.
DS
Т-34 85
HKT по-прежнему не нужны, как я понимаю?
HKT тут - чтобы реализовать кучу хелперов один раз для тайпкласса какого-нибудь функтора, а потом переиспользовать между всеми их реализациями
DS
Т.е. куча методов, например, можно было бы переиспользовать между LINQ to objects и Rx
DS
Если про дотнет говорить
DS
Если про F#, то кучу скопированных методов в модулях List и Array можно было бы не копировать
DS
Как ещё пример - это более эффективная работа с коллекциями, если её делать на Functor, Foldable и Traversable.
Т.к. это тайпклассы, то дофига динамических вызовов связанных с IEnumerable можно было бы избежать.
Т.к. это тайпклассы, то дофига динамических вызовов связанных с IEnumerable можно было бы избежать.
DS
Т-34 85
HKT по-прежнему не нужны, как я понимаю?
Ну с HKT в дотнете другая проблема. Reified дженерики. Придется как-то их начиться засовывать в рантайм и иметь их поддержку в рантайме.
Т8
Как ещё пример - это более эффективная работа с коллекциями, если её делать на Functor, Foldable и Traversable.
Т.к. это тайпклассы, то дофига динамических вызовов связанных с IEnumerable можно было бы избежать.
Т.к. это тайпклассы, то дофига динамических вызовов связанных с IEnumerable можно было бы избежать.
Это всё круто, но есть ли какая-нибудь реальная задача и 2 подхода (с и без), выраженных кодом (можно с элементами псевдокода для демонстрации)?
Т8
А то получается, что прав Фридрих, это оверкилл
DS
Т-34 85
А то получается, что прав Фридрих, это оверкилл
Т.е. убирание копипасты методов в либах - это оверкилл?
DS
Может от дженериков откажемся заодно
Т8
Т.е. убирание копипасты методов в либах - это оверкилл?
Пример из жизни, пожалуйста. Где и как возникла проблема, какие её масштабы
Dv
Т-34 85
HKT по-прежнему не нужны, как я понимаю?
Мы по-прежнему этого не знаем, нам всё ещё не показали, зачем.
Dv
Может от дженериков откажемся заодно
Как видишь, это даёт преимущества — ну, если верить авторам Scala 🤷♂️
Dv
Они говорят, что без женериков (на JVM) им проще язык поднимать, чем с женериками (на CLR).
DS
Т-34 85
Пример из жизни, пожалуйста. Где и как возникла проблема, какие её масштабы
Ну ок, пример из жизни напрямую. Это чуть отдельный подхода, но HKT он требует. Пусть у нас есть большой конфиг, в нём куча вложенных полей, они потенциально опциональны.
Есть сложная логика мерджа конфига, которая приводит в конце к тому, что опциональных значений нет.
Вариант без HKT - мы либо делаем структуру с опциональными значениями и её версию без опциональности. Таким образом у нас дублируется достаточно большой набор структур:
Вариант с HKT:
Есть сложная логика мерджа конфига, которая приводит в конце к тому, что опциональных значений нет.
Вариант без HKT - мы либо делаем структуру с опциональными значениями и её версию без опциональности. Таким образом у нас дублируется достаточно большой набор структур:
// В реальности конфиги на много десятков полей суммарноЛибо оставляем только опциональную и нам в бизнес логике придется руками постоянно кастовать значения из нуллябельных в не нуллябельные тем или иным способом.
final case class Config(address : String, featureConfig: FeatureConfig, ...)
final case class FeatureConfig(...)
final case class OptionalConfig(address: Option[String], featureConfig: Option[OptionalFeatureConfig])
final case class OptionalFeatureConfig
def merge(example: Config, external: OptinalConfig): Config = ???
Вариант с HKT:
final case class Config[F[_]](address : F[String], featureConfig: F[FeatureConfig[F]], ...)
def merge(example: Config[Id], external: Config[Option]): Config[Id] = ???
Dv
Так что, если ты искал по-настоящему абсурдную идею, то мог бы предложить что-нибудь другое. От функций отказаться или от классов :)
DS
Они говорят, что без женериков (на JVM) им проще язык поднимать, чем с женериками (на CLR).
Но дженерики в языке есть - вопрос только в реализации их в целевом байткоде