Default value for optional field

[loonydev]

Hi guys, during working on #547 I saw that optional fields don't have default parameter.

For example, for issue.createLabel user need to have instance of domain.Label with (name:String, color:String) but he must to create object like Label(None,name, None, None, color, None)

Current model

final case class Label(
    id: Option[Long],
    name: String,
    description: Option[String],
    url: Option[String],
    color: String,
    default: Option[Boolean]
)

proposal

final case class Label(
    id: Option[Long] = None,
    name: String,
    description: Option[String] = None,
    url: Option[String] = None,
    color: String,
    default: Option[Boolean] = None
)

So user can create label like Label(name = "String",color = "").

WDYT?

[juanpedromoreno]

Sounds good to me, I know those optional parameters do not need to be at the end, but if they aren’t, then you will be required to use named arguments syntax for any following arguments, as you suggested:

Label(name = "String", color = "")

Another alternative to re-order the case class is providing a companion object:

final case class Label(
        id: Option[Long],
        name: String,
        description: Option[String],
        url: Option[String],
        color: String,
        default: Option[Boolean]
    )

  object Label {
    def apply(name: String, color: String): Label = this(None, name, None, None, color, None)
  }

[loonydev]

We can move option to the end and it's reduce amount of code:

final case class Label(
    name: String,
    color: String,
    id: Option[Long] = None,
    description: Option[String] = None,
    url: Option[String] = None,
    default: Option[Boolean] = None
)

So you can use it

Label("name","color")

[loonydev]

Great, will do soon!

[fedefernandez]

@loonydev my vote is for the @juanpedromoreno's proposal. I'm not a great fan of the default values in the arguments and it's usually considered a bad practice.

[loonydev]

Hi @fedefernandez,

Well I'm agreed with you about default values, but it's Option field. Developer knows what to expect from it.
The right way it's create a few constructors for possible situation.
For example, for labels it will be:

• Create label without description Label(name,color)
• Create label with description Label(name, color, description)
• Response with label Label(*all_fields*)

And if with label it's not too complex, so what about Content which could be a File, Directory, Link and so on.

It's create huge amount of work to understand and fix all cases in domain

[fedefernandez]

@loonydev I see, thanks for the explanation. Let's go for the defaults then.