Pull to refresh

Comments 18

механизм языка интересный, а вот «пример» и «мотивация» использования (на примере той же сортировки и компаратора — «решение» заменить явную связь неявной ради экономии 1 аргумента при вызове) пока не убеждает (за восторженным текстом видно скорей желание внедрить чего-нибудь ещё нового, чем решить реальную проблему)

«И ещё нужно помнить все эти прикольные названия для в общем-то одной типовой задачи.» — обычная софистика. Понв глубокий смысл принципов SOLID отпадает необходимость помнить и знать эти «прикольные» названия.
А вот создание неявных зависимостей в коде — как раз потребует или помнить или каждый раз читать от начала до конца код, когда создаешь или меняешь implict объект.
Это экономит не только аргумент в вызове, но и избавляет от необходимости создавать и поддерживать жизненый цикл таких вспомогательных объектов. А явные связи мешают модуляризировать приложения. По поводу реальной проблемы, есть пример с обёрткой исключений, в собственном проекте тоже понадобились тайпклассы. Желание внедрять новое не всегда предосудительно.

Это просто утверждение о том, что абстракции позволяют делать общие выводы о поведении вещей. Весь код читать не надо вся информация доступна в контексте выполнения сортировки, в нашем случае.

Очень рекомендую видео, которое добавил в конце статьи. Там приводится развитие идеи, при котором всё ещё больше встаёт на свои места.

Интересно почему это называется Type classes, если это всего лишь обычные Implicit parameters?
“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 параметров, которые предоставляют расширенную информацию о предыдущих аргументах функции. Если я правильно понял)
Как раз для ответа на этот вопрос в конце статьи есть ссылка на видео. Там суть в том, что все классы для которых реализованы определённого рода адаптеры образуют некое множество классов с определённым свойством (сравнимое, выражение, число, сериализуемое в json), всё это множество, как я понимаю, и называется type class. Алгоритм объявляется для любого класса из этого множества (по сути надтипа).
Implicit parameters — это способ реализации.
Type classes — это способ объединить общим интерфейсом несвязанные между собой типы, ни чего про этот интерфейс не знающие.
Подскажите, это из этой темы, что

def sort[T](elements: Seq[T])(implicit comparator: Comparator[T]): Seq[T]

можно записать просто в виде:

def sort[T : Comparator](elements: Seq[T]): Seq[T]


В последнее время часто встречаю вторую конструкцию, но как-то провтыкал, когда она появилась. Правильно ли я понял её назначение?
Да, да, из этой. Только во втором случае, чтобы таки получить comparator придётся вызвать implicitly[Comparator[T]].
Хм, если нужно вызывать implicitly[Comparator[T]], то зачем объявлять [T : Comparator]?
[T: Comparator] означает что Т подтип Comparator. А в данном примере это не так. Поэтому такой код не корректен. Если вы понимаете о чем я:)
ан нет. это я не понимаю о чем я). сорри
перепутал [T : Comparator] с [T <: Comparator]
Вот тут хорошо о том, когда следует применять context bounds, а когда целиком implicit parameters
stackoverflow.com/a/2982293

Одно дело интерфейс, а другое — реализация. Если в определении не будет требования на нахождение в тайпклассе Comparator, то, если метод, например, абстрактный, на этапе компилляции нельзя будет проверить наличие необходимой реализации компаратора для объекта.
Если писать только в сигнатуре метода, то неясно к чему же обращаться для сравнения.

В общем одно дело — интерфейс, простой и понятный. Другое — реализация, которая может быть немного хитрой, учитывая, что разработчики библиотек чуть более искушённые люди, чем писатели прикладного кода.
Тут упростили интерфейс за счёт усложнения реализациии.
А, всё, понял. Просто я видел примеры, где доступ к неявному аргументу не нужен, он просто пробрасывался другой функции. В случае же, когда нам нужен этот аргумент, мы вызываем impicitly[...]. Теперь ясно.
def compare(Person onePerson, Person anotherPerson): Int

Чувствуется java бэкграунд :). Так в скале не пропрет.
Видимо имелось в виду

def compare(onePerson: Person, anotherPerson: Person): Int
Есть такое, у нас joint проект: пишем и на Java, и на Scala, перепутал :) Сейчас уже правильно.
а я параллельно на CoffeeScript много пишу, так постоянно путаю где нужно точки при вызове метода ставить, а где нет :) и скобочки еще там

тогда уж и вот тут:
implicit val personNameComparator = Comparator[Person] {

наверное нужно new поставить:
implicit val personNameComparator = new Comparator[Person] {
Я начинаю, кажется понимать Rúnar'а Óli, который если такое встречается, говорит: «Упс, ну это кейс-класс» или «А да, ну у меня там куча неявных преобразований...» :)
Sign up to leave a comment.