Pattern for optional-parameters in Scala using null

Question

I have a function which takes optional parameters. However, these are not Option[?] but can be either set or null:

private def div(id: String = null, cssClass: String = null): JQuery = {
  val optId = Option(id)
  val optCssClass = Option(cssClass)
  ...
  // deal with optId and optCssClass using the Scala-way™
  ...
}

I am using "null", which I know should be avoided like the plague. However, it allows me to write code like this:

div(id = "someId") // no cssClass
div(id = "otherId", cssClass = "someClass")

which to my eyes looks nicer than:

div(id = Some("someId")) // no cssClass
div(id = Some("otherId"), cssClass = Some("someClass"))

Is this a known / acceptable Scala pattern? (using null as default parameter values and converting to Option)

Or is it still heressy / bad-practice? If so, why?

Related: http://stackoverflow.com/questions/4199393/are-options-and-named-default-arguments-like-oil-and-water-in-a-scala-api — Sebastian N., Dec 29 '13 at 13:52

score 1 · Answer 1 · answered Dec 29 '13 at 11:56

1

why not replace null with empty string ?

private def div(id: String = "", cssClass: String = ""): JQuery = {
  val optId = if(id.isEmpty) None else Some(id)
  val optCssClass = if(cssClass.isEmpty) None else Some(cssClass)
  ...
  // deal with optId and optCssClass using the Scala-way™
  ...
}

then you can do:

div(id = "someId") // no cssClass
div(id = "otherId", cssClass = "someClass")

answered Dec 29 '13 at 11:56

Windor C

1,120
8
17

Why not replace null with empty string? Because it changes the semantics... The HTML that I would get would have all attributes set to empty, instead of not generating those attributes at all. – Sebastian N. Dec 29 '13 at 13:47

score 0 · Answer 2 · answered Dec 30 '13 at 08:22

One more approach I can suggest is a Builder Pattern

trait ElementBuilder {
  def identified(id: String): ElementBuilder
  def build: JQuery
}

case class DivElement(identifier: Option[String] = None) 
  extends ElementBuilder {
  def identified(id: String) = this.copy(identifier = Option(id))
  def build: JQuery = ??? // Smth like <div id={identifier}></div>
}

val builder = DivElement()
builder.identified("foo")
val element = builder.build

This approach allows you explicitly set parameters and then build you element by them

score 0 · Answer 3 · answered Dec 30 '13 at 13:07

Most of the answers here are proposing some variant of the "null object" pattern, by denoting an empty String to mean "undefined" (as in val optId = if(id.isEmpty) None else Some(id))

The catch here is that an empty string might be a valid value! This is true of any String, though you can mitigate the problem by using something really outrageous, possibly involving non-printable characters. e.g:

val UndefinedString = "THIS-IS-A-REALLY-UNLIKELY-VALID-VALUE"

private def div(
  id: String = UndefinedString,
  cssClass: String = UndefinedString
): JQuery = {
  val optId = Option(id) filter (_ != UndefinedString )
  val optCssClass = Option(cssClass) filter (_ != UndefinedString )
  ...
  // deal with optId and optCssClass using the Scala-way™
  ...
}

Better still, you could use a different type to denote your null object. As you can't subclass String you'll have to bump your params up the type hierarchy and make them CharSequences

object NullCharSeq extends CharSequence {
  def charAt(idx: Int): Char = ???
  def length(): Int = 0
  def subSequence(start: Int, end: Int): CharSequence = this
  def toString(): String = ???
}

def charSeqToOptStr(cs: CharSequence): Option[String] = cs match {
  case NullCharSeq => None
  case x => Option(x) map (_.toString)
}

private def div(
  id: CharSequence = NullCharSeq,
  cssClass: CharSequence = NullCharSeq
): JQuery = {
  val optId = charSeqToOptStr(id)
  val optCssClass = charSeqToOptStr(cssClass)
  ...
  // deal with optId and optCssClass using the Scala-way™
  ...
}

It's a heavyweight pattern for one-shot usage, but the cost is quickly amortized if you use it a lot (NullCharSeq and charSeqToOptStr only need to be defined once in the codebase).

There's also zero risk of mistakenly passing your "undefined" String as though it were a valid value. Plus, you gain the ability to directly accept CharBuffer/StringBuffer/StringBuilder as your arguments.

How is this different / better than my approach of just using null and wrapping it with Option(param), other than the emotional satisfaction of not writing that dreaded keyword? :-D Other than that, very clever solution. — Sebastian N., Dec 30 '13 at 15:14
It's definitely the emotional satisfaction :) More broadly though, Null objects like this are nicer if you're passing them between multiple methods, and it's always safe to call methods on them if correctly implemented - no risk of the infamous `NullPointerException`. That said, I've used nulls-as-defaults myself on occasion, typically when I'm creating a DSL — Kevin Wright, Dec 30 '13 at 17:28

score -1 · Answer 4 · answered Dec 29 '13 at 13:13

I would also go for a special string like the empty string in @Jiafeng's answer, if this is a sensible value. You could also define a string, like

val NoId = "?"

def div(id: String = NoId) = id match {
  case NoId => None
  case x    => Some(x)
}

Another approach would be to use another type which can be implicitly created from string or absence.

sealed trait MaybeId
implicit class Id(val name: String) extends MaybeId
case object NoId extends MaybeId

def div(id: MaybeId = NoId) = id match { 
  case NoId  => None
  case x: Id => Some(x.name)
}

Here is a general type that behaves like Option[A] with implicit conversion A => Some[A].

Matching on the argument would become cumbersome if I have 2 or 3 such optional arguments, wouldn't they? I like the suggestion of implicitly converting from T to Option[T] ... — Sebastian N., Dec 29 '13 at 13:52

Pattern for optional-parameters in Scala using null

4 Answers4

Linked