Scala -Lang рекомендуемый стиль оператора импорта: package._ или package.ClassName? - PullRequest
0 голосов
/ 04 февраля 2020

В поисках лучших Scala -Lang практика для операторов импорта. Не вижу здесь никакой рекомендации:

  1. https://docs.scala-lang.org/style/naming-conventions.html#packages
  2. https://github.com/scala/scala

Итак, что рекомендуется?

Опция (1):

import package._

Опция (2):

import package.ClassName

Ответы [ 2 ]

4 голосов
/ 04 февраля 2020

Это, как правило, дело вкуса, но есть аргумент, чтобы избежать ._, чтобы код был более устойчивым к изменениям библиотеки, которые могут вводить нежелательные символы в ваш код или создавать другие тонкие изменения в вашем коде, которые сложны выследить.

1 голос
/ 05 февраля 2020

Что касается последствий, импорт с подстановочными знаками имеет потенциальное преимущество в том, что имя неявного может изменяться без необходимости исправления операторов импорта, например, рассмотрим

object Qux {
  object Implicts {
    implicit class ExtraListOps[T](l: List[T]) {
      def shuffle: List[T] = scala.util.Random.shuffle(l)
    }
  }
}

import Qux.Implicts._
List(1,2,3,4,5).shuffle

Здесь мы мог бы переименовать ExtraListOps и все же не должен был бы изменять оператор импорта. С другой стороны, Джошуа Суерет утверждает, что :

Вы можете извлекать последствия в индивидуальном порядке без подстановочных знаков. Явный импорт имеет приоритет над импортом подстановочных знаков. Из-за этого вы можете скрывать импорт подстановочных знаков с явным импортом.

Также рассмотрите обсуждение в SIP Импорт подстановочных знаков, считающийся вредным , где, например, Ichoran заявляет

Избыточный беспорядок в верхней части каждого файла, которым может управлять только IDE, и даже не очень хорошо, но я считаю, что в большинстве случаев это гораздо более вредно. Если вы получаете противоречивые последствия, и компилятор не сообщает вам, откуда они пришли, это проблема компилятора. После обнаружения исправление становится достаточно простым (например, import org.foo.{troublesomeImplicit => _, _}).

...