Comments 3
Спасибо за статью.
Забавно, что хотя CanBuildFrom и незаменима в некоторых случаях, однако есть план в будущем попробовать избавиться от этой функции. Подробнее здесь
Забавно, что хотя CanBuildFrom и незаменима в некоторых случаях, однако есть план в будущем попробовать избавиться от этой функции. Подробнее здесь
+3
Спасибо за ссылку! Похоже, это будет значительное упрощение за счёт разумных ограничений.
0
Причём здесь разумные ограничения? Скорее отказ от старых концепций скалируемого дизайна приложений.
Старые классы коллекций олицетворяют идиоматический подход скалы. Множество мелких трейтов показывают принципы декомпозиции в условиях мультинаследования, библиотека коллекций иллюстрирует зачем вообще нужны трейты и какие преимущества от них можно получить.
Сложная параметризация типов методов показывает принципы ко-контр-вариантности и показывают пример типобезопасного программирования. Не как это принято в джаве — в любой непонятной ситуации передавай Object и используй динамический каст, а как это принято в скале — напиши два десятка лишних символов, но обеспечь корректный вывод типов.
CanBuildFrom — идеальный пример использования имплиситов. Он уместный, потому что без него задача сохранения типов при операциях не разрешима для генериков. В остальном библиотека демонстрирует умеренность и избегает неоправданного применения имплиситов. Это прям так как задумано в скале, и совсем не похоже на то, что делают из скалы хаскаляторщики, которые пихают имплиситы в каждую дырку, и даже заменяют ими наследование, хотя для JVM языка гораздо естественнее использовать наследование, встроенное в платформу, чем опирающиеся на косный язык имплиситов, которые не возможно удобно использовать без кодогенерации на уровне макропарадиза.
Отказ от этой библиотеки коллекций — это фактические признание того, что идеи, стоящие за старой скалой, были ошибочными, их требуется переработать, разработать новый идеоматический способ кодирования под скалу. И если рассматривать то предложение, на которое ссылается DDesidera, то этот способ чертовски похож на джаву. Просто с небольшим количеством сахара.
Но ведь у нас уже есть одна джава. Есть ломбок для её сахаризации. Бессмысленно тягаться с джавой на её поле, и может закончиться печально для скалы.
Старые классы коллекций олицетворяют идиоматический подход скалы. Множество мелких трейтов показывают принципы декомпозиции в условиях мультинаследования, библиотека коллекций иллюстрирует зачем вообще нужны трейты и какие преимущества от них можно получить.
Сложная параметризация типов методов показывает принципы ко-контр-вариантности и показывают пример типобезопасного программирования. Не как это принято в джаве — в любой непонятной ситуации передавай Object и используй динамический каст, а как это принято в скале — напиши два десятка лишних символов, но обеспечь корректный вывод типов.
CanBuildFrom — идеальный пример использования имплиситов. Он уместный, потому что без него задача сохранения типов при операциях не разрешима для генериков. В остальном библиотека демонстрирует умеренность и избегает неоправданного применения имплиситов. Это прям так как задумано в скале, и совсем не похоже на то, что делают из скалы хаскаляторщики, которые пихают имплиситы в каждую дырку, и даже заменяют ими наследование, хотя для JVM языка гораздо естественнее использовать наследование, встроенное в платформу, чем опирающиеся на косный язык имплиситов, которые не возможно удобно использовать без кодогенерации на уровне макропарадиза.
Отказ от этой библиотеки коллекций — это фактические признание того, что идеи, стоящие за старой скалой, были ошибочными, их требуется переработать, разработать новый идеоматический способ кодирования под скалу. И если рассматривать то предложение, на которое ссылается DDesidera, то этот способ чертовски похож на джаву. Просто с небольшим количеством сахара.
Но ведь у нас уже есть одна джава. Есть ломбок для её сахаризации. Бессмысленно тягаться с джавой на её поле, и может закончиться печально для скалы.
+3
Sign up to leave a comment.
Тонкости Scala: изучаем CanBuildFrom