Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

default no-args constructor should be generated for classes with all-optional arguments #4278

Closed
scabug opened this issue Feb 21, 2011 · 4 comments

Comments

@scabug
Copy link

scabug commented Feb 21, 2011

= problem =

For a lot of java libraries or frameworks, a default no-args constructor for a class is required. Some examples:

  • RPC
  • Serialization
  • Servlets

If you have a class with only optional arguments (like class A(i : Int = 0)), you'd expect it would work in such a situation.

There is also no easy way to access default values for constructors from java.

= analysis =

There is really no idiomatic way to create classes that adhere to such an interface in scala, see: http://stackoverflow.com/questions/4045863/scala-extra-no-arg-constructor-plus-default-constructor-parameters

It is not a very common use case, but it would improve java-scala interop by fixing this.

= enhancement recommendation =

There are two ways to fix this:

  • Generate a default constructor by default for every class where each constructor parameter is optional
  • If the overhead for such a solution is unacceptable, then a annotation marking which classes should get a default constructor could be used
@scabug
Copy link
Author

scabug commented Feb 21, 2011

Imported From: https://issues.scala-lang.org/browse/SI-4278?orig=1
Reporter: logophobia

@scabug
Copy link
Author

scabug commented Feb 21, 2011

@paulp said:
I think this is a very good idea.

@scabug
Copy link
Author

scabug commented Feb 22, 2011

@axel22 said:
We will keep this open for the moment, to be discussed during the future meetings.

@scabug
Copy link
Author

scabug commented Mar 8, 2011

@lrytz said:
in respect of language uniformity we decided not to fix this one - since it's a problem of interoperability with frameworks, we think it should not be fixed at the language level.

workarounds: repeat a default, or abstract over one, or put one default int the zero-argument constructor

class C(a: A = aDefault, b: B = C.bDefault) {
  def this() { this(b = C.bDefault) }
}
object C { def bDefault = ... }

// OR

class C(a: A = aDefault, b: B) {
  def this() { this(b = bDefault) }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant