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