Он действительно возвращает массив, как и предполагалось, и, как это удобно, нет причин, по которым вам понадобится ArrayOps, он предназначен только для предоставления дополнительных методов для массивов.Док не прав.
Процедура фактически не реализована в ArrayOps.Как и большинство методов сбора, он унаследован от TraversableLike.И в документе вы видите два метода карты:
def map [B] (f: (T) ⇒ B): ArrayOps[B]
def map [B, That] (f: (T) ⇒ B)(implicit bf: CanBuildFrom[Array[T], B, That]): That
Существует только второй (унаследованный от TraversableLike).Он предназначен для реализации карты только в одном месте (с возможностью перемещения) и всегда обеспечивает наилучшее поведение.Например, String представляет собой Seq [Char], если вы сопоставляете функцию от символа к символу, вы получаете String, но если вы отображаете из коллекции, чтобы сказать Int, результат не может быть String, и он будет простосекв.Это объяснено более подробно в статье борьба с гнилой битой с типами .
Однако это создает очень сложную сигнатуру, которая не отражает простоту использования метода, ибольшую часть времени делает очень плохую документацию (обычно вам придется искать, какой CanBuildFrom в неявной области будет работать).Это обсуждалось в самом известном вопросе о переполнении стека .Таким образом, инструмент scaladoc был расширен, так что может появиться более простая запись, соответствующая предполагаемому использованию.Если вы посмотрите на источник из GenTraversableLike
, где представлена процедура, вы увидите следующее в скалярном файле для карты (и аналогичный во многих методах)
@usecase def map[B](f: A => B): $Coll[B]
Подтипы добавляются в их документ @define Coll <className>
, и карта (среди прочих) появляется с упрощенной подписью, помеченной [Вариант использования].В источнике из ArrayOps
есть @define Coll ArrayOps
, где он должен быть Array
.