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

cycle with default arguments creates null field #5366

Open
scabug opened this issue Jan 11, 2012 · 2 comments
Open

cycle with default arguments creates null field #5366

scabug opened this issue Jan 11, 2012 · 2 comments

Comments

@scabug
Copy link

scabug commented Jan 11, 2012

class IdAndMsg(val id: Int,  val msg: String = "")

case object ObjA extends IdAndMsg(1)
case object ObjB extends IdAndMsg(2)

object IdAndMsg {
  val values = List(ObjA , ObjB)
}

object Test {
  def main(args: Array[String]): Unit = {
    ObjA
    println(IdAndMsg.values)
  }
}

/*
Output:
List(null, ObjB)
*/

The cycle is that if one references ObjA first, its superclass has a default argument which is retrieved from object IdAndMsg, which has a val which refers to ObjA, which is null.

It doesn't seem necessary - IdAndMsg.init$default$2 is a static method, but it creates IdAndMsg$ and populates the MODULE$ field so it can call IdAndMsg$.init$default$2. At least in the case of constants, the static method could return it directly and avoid loading the object.

@scabug
Copy link
Author

scabug commented Jan 11, 2012

Imported From: https://issues.scala-lang.org/browse/SI-5366?orig=1
Reporter: @paulp
Affected Versions: 2.8.1, 2.9.3, 2.10.6, 2.11.8, 2.12.0-RC1

@scabug
Copy link
Author

scabug commented May 14, 2012

@lrytz said:
I tried once implementing constructor defaults using static methods but it was not straightforward. I don't remember the details, in principle it could most likely be done.

@scabug scabug added this to the Backlog milestone Apr 7, 2017
@scala scala deleted a comment from scabug Jan 10, 2018
liufengyun added a commit to scala/scala3 that referenced this issue Jun 16, 2023
The problem is illustrated by the example below:

``` Scala
class Foo(val opposite: Foo)
case object A extends Foo(B)     // A -> B
case object B extends Foo(A)     // B -> A
```
The check aims to be simple for programmers to understand, expressive,
fast, and sound.

The check is centered around two design ideas: (1) initialization-time
irrelevance; (2) partial ordering.

The check enforces the principle of _initialization-time irrelevance_,
which means that the time when a static object is initialized should not
change program semantics. For that purpose, it enforces the following
rule:

> **The initialization of a static object should not directly or
indirectly read or write mutable state owned by another static object**.

This principle not only puts the initialization of static objects on a
solid foundation but also avoids whole-program analysis.

Partial ordering means that the initialization dependencies of static
objects form a directed-acyclic graph (DAG). No cycles with length
bigger than 1 allowed --- which might lead to deadlocks in the presence
of concurrency and strong coupling & subtle contracts between objects.

Related Issues:

#16152
#9176
#11262
scala/bug#9312
scala/bug#9115
scala/bug#9261
scala/bug#5366
scala/bug#9360
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant