Proposal: A shorthand way of repassing scala 2.8 default arguments to super constructor calls

[David Ziegler]

I would like to propose a shorthand way of repassing scala 2.8 default
arguments to super constructor calls.

For example, given a Shape class as follows:

class Shape (x: Int, y: Int, color: String = "black", fillcolor:
String = "white")

I would like to be able to extend Shape like this:

class Circle (x: Int, y: Int, radius: Int, _=_) extends Shape (x, y, _=_)

Where the _=_ magic parameter in the constructor parameter list and
super call are a shorthand for respecifying, and then passing though
all the default parameters from the super constructor.  The above
class Circle would expand to:

class Circle (x: Int, y: Int, radius: Int, color: String = "black",
fillcolor: String = "white") extends Shape (x, y, color=color,
fillcolor=fillcolor)


Notes:

- without this scheme, every time a new default argument is added every
  subclass will have to be revised.
- writing the Circle subclass by hand with the current named argument scheme
  would actually be much more verbose than my example: it would rarely be
  acceptable to repeat the specific default values in each subclass, so the
  the defaults would have to be moved to a companion object.
- the same mechanism could be used for super-method calls (not nearly
as needed though)
- this scheme could probably be extended to allow traits to have
contructor parameters as
  long as they all had default values.

What do you think?

- Regards

David Ziegler

[Daniel Sobral]

Looks interesting, but do we want that for Scala 2.8? I feel it would be better if we let default/named parameters in the wild before we start adding to them.

On Thu, Oct 1, 2009 at 7:50 AM, David Ziegler <dz@...> wrote:

I would like to propose a shorthand way of repassing scala 2.8 default
arguments to super constructor calls.

For example, given a Shape class as follows:

class Shape (x: Int, y: Int, color: String = "black", fillcolor:
String = "white")

I would like to be able to extend Shape like this:

class Circle (x: Int, y: Int, radius: Int, _=_) extends Shape (x, y, _=_)

Where the _=_ magic parameter in the constructor parameter list and
super call are a shorthand for respecifying, and then passing though
all the default parameters from the super constructor.  The above
class Circle would expand to:

class Circle (x: Int, y: Int, radius: Int, color: String = "black",
fillcolor: String = "white") extends Shape (x, y, color=color,
fillcolor=fillcolor)


Notes:

- without this scheme, every time a new default argument is added every
 subclass will have to be revised.
- writing the Circle subclass by hand with the current named argument scheme
 would actually be much more verbose than my example: it would rarely be
 acceptable to repeat the specific default values in each subclass, so the
 the defaults would have to be moved to a companion object.
- the same mechanism could be used for super-method calls (not nearly
as needed though)
- this scheme could probably be extended to allow traits to have
contructor parameters as
 long as they all had default values.

What do you think?

- Regards

David Ziegler

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

[David Ziegler]

My real point, which was probably lost because I included a concrete proposal is this:

Combining named/default arguments with subclassing seems to require a lot of repetitive boilerplate code.

Furthermore, there is a strong tension behind a major motivation for default arguments - that new parameters can be added without breaking use points - and how things play out with subclassing:  Every subclass has to be found and edited in order to pass the new default argument to the superclass.

This is extra important in scala (as opposed to java), because if one is using immutable objects, then the convenience  and flexibility of constructor arguments becomes much more important.  (ie. no builders, setters etc which are the java ways around this).

Here is a an example of what I mean:

object Shape {
  // these are required here to avoid having to repeat the actual default values in the subclass.
  val defaultColor = "black"
  val defaultFillColor = "white"
}

class Shape (x: Int, y: Int, color: String = Shape.defaultColor, fillcolor: String = Shape.defaultFillColor)

class Circle (x: Int, y: Int, radius: Int, color: String = Shape.defaultColor, fillcolor: String = Shape.defaultFillColor) extends Shape (x, y, color=color, fillcolor=fillcolor)


Whereas the intent is more like (using my proposal as an example):

class Shape (x: Int, y: Int, color: String = "black", fillcolor: String = "white")

class Circle (x: Int, y: Int, radius: Int, _=_) extends Shape (x, y, _=_)

- Regards

David Ziegler

On Thu, Oct 1, 2009 at 8:52 AM, Daniel Sobral <dcsobral@...> wrote:

Looks interesting, but do we want that for Scala 2.8? I feel it would be better if we let default/named parameters in the wild before we start adding to them.

On Thu, Oct 1, 2009 at 7:50 AM, David Ziegler <dz@...> wrote:

I would like to propose a shorthand way of repassing scala 2.8 default
arguments to super constructor calls.

For example, given a Shape class as follows:

class Shape (x: Int, y: Int, color: String = "black", fillcolor:
String = "white")

I would like to be able to extend Shape like this:

class Circle (x: Int, y: Int, radius: Int, _=_) extends Shape (x, y, _=_)

Where the _=_ magic parameter in the constructor parameter list and
super call are a shorthand for respecifying, and then passing though
all the default parameters from the super constructor.  The above
class Circle would expand to:

class Circle (x: Int, y: Int, radius: Int, color: String = "black",
fillcolor: String = "white") extends Shape (x, y, color=color,
fillcolor=fillcolor)


Notes:

- without this scheme, every time a new default argument is added every
 subclass will have to be revised.
- writing the Circle subclass by hand with the current named argument scheme
 would actually be much more verbose than my example: it would rarely be
 acceptable to repeat the specific default values in each subclass, so the
 the defaults would have to be moved to a companion object.
- the same mechanism could be used for super-method calls (not nearly
as needed though)
- this scheme could probably be extended to allow traits to have
contructor parameters as
 long as they all had default values.

What do you think?

- Regards

David Ziegler

--
Daniel C. Sobral

Something I learned in academia: there are three kinds of academic reviews: review by name, review by reference and review by value.

[Justin du coeur]

Big +1.  Don't know if it fits into 2.8, but it's a reasonable-looking solution for a problem I routinely hit in languages that allow default parameter lists...

On Thu, Oct 1, 2009 at 6:50 AM, David Ziegler <dz@...> wrote:

I would like to propose a shorthand way of repassing scala 2.8 default
arguments to super constructor calls.

For example, given a Shape class as follows:

class Shape (x: Int, y: Int, color: String = "black", fillcolor:
String = "white")

I would like to be able to extend Shape like this:

class Circle (x: Int, y: Int, radius: Int, _=_) extends Shape (x, y, _=_)

Where the _=_ magic parameter in the constructor parameter list and
super call are a shorthand for respecifying, and then passing though
all the default parameters from the super constructor.  The above
class Circle would expand to:

class Circle (x: Int, y: Int, radius: Int, color: String = "black",
fillcolor: String = "white") extends Shape (x, y, color=color,
fillcolor=fillcolor)


Notes:

- without this scheme, every time a new default argument is added every
 subclass will have to be revised.
- writing the Circle subclass by hand with the current named argument scheme
 would actually be much more verbose than my example: it would rarely be
 acceptable to repeat the specific default values in each subclass, so the
 the defaults would have to be moved to a companion object.
- the same mechanism could be used for super-method calls (not nearly
as needed though)
- this scheme could probably be extended to allow traits to have
contructor parameters as
 long as they all had default values.

What do you think?

- Regards

David Ziegler