Являются ли параметры и именованные аргументы по умолчанию в Scala API такими же, как нефть и вода?

Вот еще одно решение, частично вдохновленное ответ Криса. Он также включает в себя оболочку, но оболочка прозрачна, вам нужно определить ее только один раз, и пользователю API не нужно импортировать какие-либо преобразования:

class Opt[T] private (val option: Option[T])
object Opt {
   implicit def any2opt[T](t: T): Opt[T] = new Opt(Option(t)) // NOT Some(t)
   implicit def option2opt[T](o: Option[T]): Opt[T] = new Opt(o)
   implicit def opt2option[T](o: Opt[T]): Option[T] = o.option
}

case class Gather(finishOnKey: Char = '#', 
                  numDigits: Opt[Int] = None, // Infinite
                  callbackUrl: Opt[String] = None, 
                  timeout: Int = 5
                 ) extends Verb

// this works with no import
Gather(numDigits = 4, callbackUrl = "http://xxx")
// this works too
Gather(numDigits = 4, callbackUrl = Some("http://xxx"))
// you can even safely pass the return value of an unsafe Java method
Gather(callbackUrl = maybeNullString())

Что касается более серьезной проблемы дизайна, я не думаю, что взаимодействие между Опциями и именованными параметрами по умолчанию так сильно зависит от масла и воды, как может показаться на первый взгляд. Существует явное различие между необязательным полем и полем со значением по умолчанию. Необязательное поле (например, поле типа Option[T]) может никогда не иметь значения. С другой стороны, поле со значением по умолчанию просто не требует, чтобы его значение передавалось в качестве аргумента конструктору. Таким образом, эти два понятия ортогональны, и неудивительно, что поле может быть необязательным и иметь значение по умолчанию.

Тем не менее, я думаю, что можно привести разумный аргумент в пользу использования Opt, а не Option для таких полей, помимо простого сохранения клиентом некоторого набора текста. Это делает API более гибким в том смысле, что вы можете заменить аргумент T аргументом Opt[T] (или наоборот), не нарушая вызывающих объектов конструктора [1].

Что касается использования значения null по умолчанию для публичного поля, я думаю, что это плохая идея. «Вы» можете знать, что ожидаете null, но клиенты, которые обращаются к полю, могут не знать. Даже если поле является частным, использование null вызовет проблемы в будущем, когда другим разработчикам придется поддерживать ваш код. Здесь вступают в игру все обычные аргументы о значениях null - я не думаю, что этот вариант использования является каким-либо особым исключением.

[1] При условии, что вы удалили преобразование option2opt, так что вызывающие абоненты должны передавать T всякий раз, когда требуется Opt[T].

Не конвертируйте ничего автоматически в Option. Используя мой ответ здесь, я думаю, вы можете сделать это красиво, но в типичном виде. способ.

sealed trait NumDigits { /* behaviour interface */ }
sealed trait FallbackUrl { /* behaviour interface */ }
case object NoNumDigits extends NumDigits { /* behaviour impl */ }
case object NofallbackUrl extends FallbackUrl { /* behaviour impl */ }

implicit def int2numd(i : Int) = new NumDigits { /* behaviour impl */ }
implicit def str2fallback(s : String) = new FallbackUrl { /* behaviour impl */ }

class Gather(finishOnKey: Char = '#', 
              numDigits: NumDigits = NoNumDigits, // Infinite
              fallbackUrl: FallbackUrl = NoFallbackUrl, 
              timeout: Int = 5

Затем вы можете называть его как хотите - очевидно, добавляя свои методы поведения к FallbackUrl и NumDigits в зависимости от ситуации. Главный минус здесь в том, что это тонна шаблонного

Gather(numDigits = 4, fallbackUrl = "http://wibble.org")

Лично я считаю, что использование null в качестве значения по умолчанию здесь совершенно нормально. Использование Option вместо null - это когда вы хотите донести до своих клиентов, что что-то не может быть определено. Таким образом, возвращаемое значение может быть объявлено Option [...] или аргументом метода для абстрактных методов. Это избавляет клиента от чтения документации или, что более вероятно, от получения NPE из-за того, что он не понимает, что что-то может быть нулевым.

В вашем случае вы знаете, что там может быть нуль. И если вам нравятся методы Option, просто введите val optionalFallbackUrl = Option(fallbackUrl) в начале метода.

Однако этот подход работает только для типов AnyRef. Если вы хотите использовать тот же метод для любого аргумента (без использования Integer.MAX_VALUE в качестве замены null), тогда, я думаю, вам следует выбрать один из других ответов

Я думаю, что до тех пор, пока в Scala нет поддержки языка для реального вида void (объяснение ниже) «type», использование Option, вероятно, будет более чистым решением в долгосрочной перспективе. Возможно даже для всех параметров по умолчанию.

Проблема в том, что люди, использующие ваш API, знают, что некоторые из ваших аргументов заданы по умолчанию, могут также обрабатывать их как необязательные. Итак, они объявляют их как

var url: Option[String] = None

Все красиво и чисто, и они могут просто подождать и посмотреть, получат ли они когда-нибудь информацию, чтобы заполнить эту опцию.

Когда вы наконец вызовете ваш API с аргументом по умолчанию, они столкнутся с проблемой.

// Your API
case class Gather(url: String) { def this() = { ... } ... }

// Their code
val gather = url match {
  case Some(u) => Gather(u)
  case _ => Gather()
}

Думаю, тогда было бы намного проще это сделать

val gather = Gather(url.openOrVoid)

где *openOrVoid просто не учитывается в случае None. Но это невозможно.

Поэтому вам действительно следует подумать о том, кто будет использовать ваш API и как они могут его использовать. Вполне возможно, что ваши пользователи уже используют Option для хранения всех переменных именно по той причине, что они знают, что в конце концов они являются необязательными ...

Параметры по умолчанию хороши, но они также усложняют ситуацию; особенно когда вокруг уже есть Option тип. Думаю, в вашем втором вопросе есть доля правды.

Могу я просто поспорить в пользу вашего существующего подхода, Some("callbackUrl")? Это все еще 6 символов, которые пользователь API должен ввести, показывает им, что параметр является необязательным, и, по-видимому, упрощает реализацию для вас.

Я думаю, тебе следует стиснуть зубы и приступить к Option. Я сталкивался с этой проблемой раньше, и обычно она исчезла после некоторого рефакторинга. Иногда этого не происходило, и я жил с этим. Но факт заключается в том, что параметр по умолчанию не является «необязательным» параметром - это просто параметр, имеющий значение по умолчанию.

Я в значительной степени поддерживаю Debilski ответ.

Меня это тоже удивило. Почему бы не обобщить на:

implicit def any2Option[T](x: T): Option[T] = Some(x)

Есть ли причина, по которой это не могло быть просто частью Predef?