Многие начинающие и не очень Scala разработчики принимают implicits как умеренно полезную возможность. Использование обычно ограничивается передачей ExecutionContext
во Future
. Другие же избегают неявного и считают возможность вредной.
Код же вроде этого вообще многих пугает:
implicit def function(implicit argument: A): B
Но я считаю этот механизм важным преимуществом языка, давайте разберемся почему.
Кратко про implicits
В целом implicits это механизм автоматического дополнения кода при компиляции:
-
для неявных аргументов автоматически подставляется значение
-
для неявных преобразований значение автоматически оборачивается в вызов метода
Я не буду углубляться в эту тему, кому интересно посмотрите об этом видео от создателя языка. Вкратце один этот механизм используется в нескольких разных случаях (и в Scala 3 будет разделен на несколько отдельных возможностей):
-
Передача неявного контекста (как
ExecutionContext
) -
Неявные преобразования (не рекомендуется к использованию)
-
Методы-расширения (extension methods, синтаксический сахар по добавлению методов к существующим типам)
-
Классы типов (type classes) и неявный вывод (implicit resolution)
Классы типов и неявный вывод
Сами по себе классы тыпов не несут какой-то новизны или революции – это попросту реализация методов «для» типа, а не «в самом» типе, это как разница между Comparable
& Ordering
(Comparator
в Java):
Comparable
реализуется для добавления возможности сравнения в ООП стиле:
class Person(age: Int) extends Comparable[Person] { override def compareTo(o: Person): Int = age compareTo o.age } def max[T <: Comparable[T]](xs: Iterable[T]): T = xs.reduce[T] { case (a, b) if (a compareTo b) < 0 => b case (a, _) => a }
Ordering
реализуется с той же целью, но отдельно от самого типа:
case class Person(age: Int) implicit object ByAgeOrdering extends Ordering[Person] { override def compare(o1: Person, o2: Person): Int = o1.age compareTo o2.age } def max[T: Ordering](xs: Iterable[T]): T = xs.reduce[T] { case (a, b) if Ordering[T].lt(a, b) => b case (a, _) => a } // is syntactic sugar for def max[T](xs: Iterable[T])(implicit evidence: Ordering[T]): T = ...
Вот и весь класс типов.
Интересным этот механизм делает неявный вывод. Вернемся к непонятному объявлению из начала статьи и добавим к нему разные комбинации:
implicit val value: A = ??? implicit def definition: B = ??? implicit def conversion(argument: C): D = ??? implicit def function(implicit argument: E): F = ???
В чем разница? Исключая conversion
, который является неявным преобразованием, почти ни в чем: value
, definition
& function
могут быть использованы чтобы подставить значение для неявного аргумента нужного типа. Разница только в способе вычисления: val
статичен, а def
вычисляется каждый раз при постановке. Неявный аргумент в такой функции работает как обычно – требует неявного значения в скоупе.
Неявная функция с неявным аргументом дает нам довольно интересные возможности – выходит компилятор может не просто подставить неявное значение в нужное место, но и скомбинировать несколько вызовов для получения нужного значения, подобрав подходящие функции.
Рассмотрим пример – мы можем описать порядок пар любых типов, для этого не нужно знать их заранее – достаточно знать, что у них тоже есть порядок:
implicit def pairOrder[A: Ordering, B: Ordering]: Ordering[(A, B)] = { case ((a1, b1), (a2, b2)) if Ordering[A].equiv(a1, a2) => Ordering[B].compare(b1, b2) case ((a1, _), (a2, _)) => Ordering[A].compare(a1, a2) } // again, just syntactic sugar for: implicit def pairOrder[A, B](implicit a: Ordering[A], b: Ordering[B]): Ordering[(A, B)] = ...
Теперь если вдруг нам понадобится найти максимум среди сложных структур компилятор сам построит подходящий объект, комбинируя пользовательские и стандартные объявления:
val values = Seq( (Person(30), ("A", "A")), (Person(30), ("A", "B")), (Person(20), ("A", "C")) ) max(values) // => (Person(30),(A,B))
У нас был список типа Seq[(Person, (String, String))]
и компилятор смог сам подобрать комбинацию функций для построения Ordering
для этого типа:
max(values)( pairOrder( ByAgeOrdering, pairOrder(Ordering.String, Ordering.String) ) )
Так неявный вывод позволяет описывать общие правила вывода и поручить компилятору свести эти правила вместе и получить конкретную имплементацию класса типов. Добавляя собственный тип или собственные правила не нужно описывать все с начала – компилятор скомбинирует все сам, чтобы получить нужный объект.
А главное, если компилятору это не удастся – вы получите ошибку компиляции, а не времени выполнения и сможете исправить проблему сразу на месте. Хотя конечно в бочке меда не без ложки дегтя – если у компилятора не вышло, вы не знаете какого звена в цепочке не хватило – дебажить такое не всегда просто.
Надеюсь неявное стало теперь немного более явным.
ссылка на оригинал статьи https://habr.com/ru/post/549592/
Добавить комментарий