From e5536e67a8915d469346923f3b485bff571d9ded Mon Sep 17 00:00:00 2001 From: Dmitry Petrashko Date: Tue, 14 Feb 2017 14:19:10 +0100 Subject: [PATCH] @static: fix code samples in html --- sips/pending/_posts/2016-01-11-static-members.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/sips/pending/_posts/2016-01-11-static-members.md b/sips/pending/_posts/2016-01-11-static-members.md index 50d32cb2c9..d248ec7027 100644 --- a/sips/pending/_posts/2016-01-11-static-members.md +++ b/sips/pending/_posts/2016-01-11-static-members.md @@ -155,7 +155,6 @@ These rules exist to enforce the unlikelyhood of an observable difference in sem The restrictions in this SIP make it hard to observe changes in initialization within the same object. It is still possible to observe those changes using multiple classes and side effects within initializers: -```scala {% highlight scala %} class C { val x = {println("x"); 1 } @@ -176,7 +175,7 @@ object Os extends C { // x } {% endhighlight %} -``` + Static fields can be initialized earlier than they used to be initialized while being non-static, but never later. By requiring `@static` first to be defined first inside the object, @@ -189,7 +188,7 @@ Unlike `@tailrec` this annotation does affect the binary API and dropping such a An alternative to this proposal would be to emit all the fields defined in objects as static. Unfortunately this gets us under dark waters when we try to figure out in the following example: -``` + {% highlight scala %} class Super { val c = {println(1); 1} @@ -199,7 +198,7 @@ object Object extends Super { val d = {println(3); 2} } {% endhighlight %} -``` + Let's consider possible options: - if the field `c` is emitted as `static` on the bytecode level, it will be initialized before the `c` in superclass is initialized, reordering side-effects in initializers;