Scala API中是否包含选项和命名的默认参数，例如油和水? [英] Are Options and named default arguments like oil and water in a Scala API?

问题描述

我正在使用Scala API(顺便说一下，对于Twilio而言)，其中操作具有大量参数，并且其中许多参数具有合理的默认值.为了减少类型输入并提高可用性，我决定使用带有named和default参数的案例类.例如TwiML Gather动词:

I'm working on a Scala API (for Twilio, by the way) where operations have a pretty large amount of parameters and many of these have sensible default values. To reduce typing and increase usability, I've decided to use case classes with named and default arguments. For instance for the TwiML Gather verb:

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

此处感兴趣的参数是 callbackUrl .在没有提供任何值的情况下，它是真正可选的唯一参数，将不应用任何值(这是完全合法的).

The parameter of interest here is callbackUrl. It is the only parameter which is really optional in the sense that if no value is supplied, no value will be applied (which is perfectly legal).

为了在API的实现端使用它来执行monadic map例程，我已经声明了它为选项，但这给API用户带来了一些额外的负担:

I've declared it as an option in order to do the monadic map routine with it on the implementation side of the API, but this puts some extra burden on the API user:

Gather(numDigits = 4, callbackUrl = Some("http://xxx"))
// Should have been
Gather(numDigits = 4, callbackUrl = "http://xxx")

// Without the optional url, both cases are similar
Gather(numDigits = 4)

据我所知，有两种选择(无双关语)可以解决此问题.使API客户端将隐式转换导入范围:

As far as I can make out, there are two options (no pun intended) to resolve this. Either make the API client import an implicit conversion into scope:

implicit def string2Option(s: String) : Option[String] = Some(s)

或者我可以用空默认值重新声明case类，并将其转换为实现方面的一个选项:

Or I can redeclare the case class with a null default and convert it to an option on the implementation side:

case class Gather(finishOnKey: Char = '#', 
                  numDigits: Int = Integer.MAX_VALUE, 
                  callbackUrl: String = null, 
                  timeout: Int = 5
                  ) extends Verb

我的问题如下:

1. 有没有更优雅的方式来解决我的特殊情况?
2. 更一般而言:命名参数是一种新的语言功能(2.8).事实证明，选项和命名的默认参数就像油和水一样吗? :)
3. 在这种情况下，使用空默认值可能是最好的选择吗?

推荐答案

这是另一种解决方案，部分受

Here's another solution, partly inspired by Chris' answer. It also involves a wrapper, but the wrapper is transparent, you only have to define it once, and the user of the API doesn't need to import any conversions:

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]的字段)可能从不具有值.另一方面，具有默认值的字段根本不需要将其值作为构造函数的参数提供.因此，这两个概念是正交的，因此字段是可选字段并具有默认值也就不足为奇了.

---

To address the larger design issue, I don't think that the interaction between Options and named default parameters is as much oil-and-water as it might seem at first glance. There's a definite distinction between an optional field and one with a default value. An optional field (i.e. one of type Option[T]) might never have a value. A field with a default value, on the other hand, simply does not require its value to be supplied as an argument to the constructor. These two notions are thus orthogonal, and it's no surprise that a field may be optional and have a default value.

这就是说，我认为可以为使用Opt而不是Option这类字段做出合理的论点，而不仅仅是为客户端节省一些键入内容.这样做可以使API更加灵活，从某种意义上说，您可以用Opt[T]自变量替换T自变量(反之亦然)，而不会破坏构造函数的调用者[1].

That said, I think a reasonable argument can be made for using Opt rather than Option for such fields, beyond just saving the client some typing. Doing so makes the API more flexible, in the sense that you can replace a T argument with an Opt[T] argument (or vice-versa) without breaking callers of the constructor[1].

至于将null默认值用于公共字段，我认为这是一个坏主意. 您"可能知道您希望使用null，但是访问该字段的客户端可能不会.即使该字段是私有的，当其他开发人员必须维护您的代码时，使用null仍会带来麻烦.关于null值的所有常规参数都在这里起作用-我认为这个用例不是任何特殊的例外.

As for using a null default value for a public field, I think this is a bad idea. "You" may know that you expect a null, but clients that access the field may not. Even if the field is private, using a null is asking for trouble down the road when other developers have to maintain your code. All the usual arguments about null values come into play here -- I don't think this use case is any special exception.

[1]前提是您删除了option2opt转换，以便在需要Opt[T]时调用者必须传递T.

[1] Provided that you remove the option2opt conversion so that callers must pass a T whenever an Opt[T] is required.

这篇关于Scala API中是否包含选项和命名的默认参数，例如油和水?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！