Как я формирую объединение scala SortedMaps?

Вы выбрали крепкий орешек, будучи новичком в Scala! : -)

Хорошо, краткая экскурсия, не ждите, что сейчас полностью ее поймете. Во-первых, обратите внимание, что проблема возникает в методе ++ . В поисках его определения мы находим его у признака MapLike , получая либо Iterator , либо Traversable . Поскольку y представляет собой SortedMap , то используется версия Traversable .

Обратите внимание, что в его обширной сигнатуре типа имеется CanBuildFrom передается. Он передается неявно, поэтому обычно вам не о чем беспокоиться. Однако, чтобы понять, что происходит, на этот раз вы это сделаете.

Вы можете найти CanBuildFrom, щелкнув его в том месте, где он указан в определении ++ , или с помощью фильтрации. Как упоминал Рэндалл в комментариях, в верхнем левом углу страницы скалярной документации есть немаркированное пустое поле. Вам просто нужно щелкнуть там и ввести, и он вернет совпадения для всего, что вы набрали.

Итак, найдите типаж CanBuildFrom в ScalaDoc и выберите его. Он имеет большое количество подклассов, каждый из которых отвечает за создание определенного типа коллекции. Найдите и щелкните подкласс SortedMapCanBuildFrom . Это класс объекта, который вам нужен для создания SortedMap из Traversable . Обратите внимание на конструктор экземпляра (конструктор класса), который получает неявный параметр Ordering . Теперь мы приближаемся.

На этот раз используйте фильтр filter для поиска Ordering . Его сопутствующий объект (щелкните на маленьком «о» имени) содержит неявный объект, который будет генерировать Ordering s, поскольку сопутствующие объекты исследуются на предмет имплицитного создания экземпляров или преобразований для этого класса. Он определен внутри трейта LowPriorityOrderingImplicits , который расширяет объект Ordering , и, глядя на него, вы увидите метод упорядоченный [A <: Ordered [A]] , который создаст Требуется упорядочивание ... или произведет его, если бы не было проблемы.

Можно было бы предположить, что неявного преобразования из X в Упорядоченный [X] будет достаточно, как и я до того, как рассмотрел это более внимательно. Это, однако, преобразование объектов , а упорядоченный ожидает получения типа , который является подтипом Упорядоченный [X] . Хотя можно преобразовать объект типа X в объект типа Ordered [X] , X сам по себе не является подтипом Ordered [X] , поэтому его нельзя передать в качестве параметра упорядоченному .

С другой стороны, вы можете создать неявное val Ordering [X] вместо def Ordered [X] , и вы обойти проблему. В частности:

object ViewBoundExample {
    class X
    def combine[Y](a: SortedMap[X, Y], b: SortedMap[X, Y]): SortedMap[X, Y] = {
        a ++ b
    }
    implicit val orderingX = new Ordering[X] { def compare(x: X, y: X) = 0 }
}

Я думаю, что у большинства людей первоначальная реакция на Упорядоченный / Порядок должна вызывать недоумение: зачем нужны классы для одного и того же? Первый расширяет java.lang.Comparable , тогда как второй расширяет java.util.Comparator . Увы, подпись типа для compare в значительной степени суммирует основное различие:

def compare(that: A): Int     // Ordered
def compare(x: T, y: T): Int  // Ordering

Использование упорядоченного [A] требует, чтобы либо A расширяли Упорядоченный [A] , что потребует от человека возможности изменить определение A или передать метод, который может преобразовать A в Заказанный [A] . Scala прекрасно справляется с последним, но тогда у вас есть для преобразования каждого экземпляра перед сравнением.

С другой стороны, использование Упорядочивание [A] требует создания одного объекта, как показано выше. Когда вы его используете, вы просто передаете два объекта типа A в compare - в процессе не создаются объекты.

Таким образом, можно добиться некоторого прироста производительности, но есть гораздо более важная причина, по которой Scala предпочитает Упорядочивание над Упорядоченное . Еще раз посмотрите на сопутствующий объект в Упорядочивание . Вы заметите, что для многих классов Scala, определенных в нем, есть несколько имплицитов. Как вы помните, я упоминал ранее, что неявный для класса T будет искать внутри сопутствующего объекта T , и это именно то, что происходит.

Это может быть сделано и для Упорядоченных . Однако, и это является камнем преткновения, это означает, что любой метод, поддерживающий как Упорядочивание , так и Упорядоченное , не сработает! Это потому, что Scala будет искать неявное, чтобы заставить его работать, и найдет два: один для Ordering , один для Ordered . Поскольку Scala не может решить, что именно вам нужно, выдает сообщение об ошибке. Итак, выбор должен был быть сделан, и Заказ потребовал дополнительных действий.

Да, я забыл объяснить, почему подпись не определяется как заказанный [A <% Заказанный [A]] вместо заказанный [A <: заказанный [A]] . Я подозреваю, что это приведет к двойной имплицитной неудаче, о которой я упоминал ранее, но я