Comments 18
механизм языка интересный, а вот «пример» и «мотивация» использования (на примере той же сортировки и компаратора — «решение» заменить явную связь неявной ради экономии 1 аргумента при вызове) пока не убеждает (за восторженным текстом видно скорей желание внедрить чего-нибудь ещё нового, чем решить реальную проблему)
«И ещё нужно помнить все эти прикольные названия для в общем-то одной типовой задачи.» — обычная софистика. Понв глубокий смысл принципов SOLID отпадает необходимость помнить и знать эти «прикольные» названия.
А вот создание неявных зависимостей в коде — как раз потребует или помнить или каждый раз читать от начала до конца код, когда создаешь или меняешь implict объект.
«И ещё нужно помнить все эти прикольные названия для в общем-то одной типовой задачи.» — обычная софистика. Понв глубокий смысл принципов SOLID отпадает необходимость помнить и знать эти «прикольные» названия.
А вот создание неявных зависимостей в коде — как раз потребует или помнить или каждый раз читать от начала до конца код, когда создаешь или меняешь implict объект.
0
Это экономит не только аргумент в вызове, но и избавляет от необходимости создавать и поддерживать жизненый цикл таких вспомогательных объектов. А явные связи мешают модуляризировать приложения. По поводу реальной проблемы, есть пример с обёрткой исключений, в собственном проекте тоже понадобились тайпклассы. Желание внедрять новое не всегда предосудительно.
Это просто утверждение о том, что абстракции позволяют делать общие выводы о поведении вещей. Весь код читать не надо вся информация доступна в контексте выполнения сортировки, в нашем случае.
Очень рекомендую видео, которое добавил в конце статьи. Там приводится развитие идеи, при котором всё ещё больше встаёт на свои места.
Это просто утверждение о том, что абстракции позволяют делать общие выводы о поведении вещей. Весь код читать не надо вся информация доступна в контексте выполнения сортировки, в нашем случае.
Очень рекомендую видео, которое добавил в конце статьи. Там приводится развитие идеи, при котором всё ещё больше встаёт на свои места.
0
Интересно почему это называется Type classes, если это всего лишь обычные Implicit parameters?
+1
“Another thing to know about implicit parameters is that they are perhaps most often used to provide information about a type mentioned explicitly in an earlier parameter list, similar to the type classes of Haskell”
Типа частный случай implicit параметров, которые предоставляют расширенную информацию о предыдущих аргументах функции. Если я правильно понял)
Типа частный случай implicit параметров, которые предоставляют расширенную информацию о предыдущих аргументах функции. Если я правильно понял)
0
Как раз для ответа на этот вопрос в конце статьи есть ссылка на видео. Там суть в том, что все классы для которых реализованы определённого рода адаптеры образуют некое множество классов с определённым свойством (сравнимое, выражение, число, сериализуемое в json), всё это множество, как я понимаю, и называется type class. Алгоритм объявляется для любого класса из этого множества (по сути надтипа).
+1
Implicit parameters — это способ реализации.
Type classes — это способ объединить общим интерфейсом несвязанные между собой типы, ни чего про этот интерфейс не знающие.
Type classes — это способ объединить общим интерфейсом несвязанные между собой типы, ни чего про этот интерфейс не знающие.
0
Подскажите, это из этой темы, что
можно записать просто в виде:
В последнее время часто встречаю вторую конструкцию, но как-то провтыкал, когда она появилась. Правильно ли я понял её назначение?
def sort[T](elements: Seq[T])(implicit comparator: Comparator[T]): Seq[T]
можно записать просто в виде:
def sort[T : Comparator](elements: Seq[T]): Seq[T]
В последнее время часто встречаю вторую конструкцию, но как-то провтыкал, когда она появилась. Правильно ли я понял её назначение?
0
Да, да, из этой. Только во втором случае, чтобы таки получить comparator придётся вызвать implicitly[Comparator[T]].
0
Хм, если нужно вызывать
implicitly[Comparator[T]]
, то зачем объявлять [T : Comparator]
? 0
[T: Comparator] означает что Т подтип Comparator. А в данном примере это не так. Поэтому такой код не корректен. Если вы понимаете о чем я:)
0
Вот тут хорошо о том, когда следует применять context bounds, а когда целиком implicit parameters
stackoverflow.com/a/2982293
stackoverflow.com/a/2982293
0
Одно дело интерфейс, а другое — реализация. Если в определении не будет требования на нахождение в тайпклассе Comparator, то, если метод, например, абстрактный, на этапе компилляции нельзя будет проверить наличие необходимой реализации компаратора для объекта.
Если писать только в сигнатуре метода, то неясно к чему же обращаться для сравнения.
В общем одно дело — интерфейс, простой и понятный. Другое — реализация, которая может быть немного хитрой, учитывая, что разработчики библиотек чуть более искушённые люди, чем писатели прикладного кода.
Тут упростили интерфейс за счёт усложнения реализациии.
Если писать только в сигнатуре метода, то неясно к чему же обращаться для сравнения.
В общем одно дело — интерфейс, простой и понятный. Другое — реализация, которая может быть немного хитрой, учитывая, что разработчики библиотек чуть более искушённые люди, чем писатели прикладного кода.
Тут упростили интерфейс за счёт усложнения реализациии.
0
def compare(Person onePerson, Person anotherPerson): Int
Чувствуется java бэкграунд :). Так в скале не пропрет.
Видимо имелось в виду
def compare(onePerson: Person, anotherPerson: Person): Int
Чувствуется java бэкграунд :). Так в скале не пропрет.
Видимо имелось в виду
def compare(onePerson: Person, anotherPerson: Person): Int
0
Есть такое, у нас joint проект: пишем и на Java, и на Scala, перепутал :) Сейчас уже правильно.
0
а я параллельно на CoffeeScript много пишу, так постоянно путаю где нужно точки при вызове метода ставить, а где нет :) и скобочки еще там
тогда уж и вот тут:
наверное нужно new поставить:
тогда уж и вот тут:
implicit val personNameComparator = Comparator[Person] {
наверное нужно new поставить:
implicit val personNameComparator = new Comparator[Person] {
0
Sign up to leave a comment.
Type classes в Scala