8000 Revert `@static` annotation by gkossakowski · Pull Request #1340 · scala/scala · GitHub
[go: up one dir, main page]

Skip to content

Revert @static annotation #1340

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

Merged
merged 8 commits into from
Sep 18, 2012

Conversation

gkossakowski
Copy link
Contributor

This pull request reverts all changes related to @static feature.

As it has been discussed on scala-internals this feature should come with SIP in the first place. We need much more time hash out the details of @static semantics which we don't have at the moment given how close the RC1 is.

Review by @axel22.

This reverts commit cb393fc.

Conflicts:

	src/compiler/scala/tools/nsc/backend/icode/GenICode.scala
This reverts commit 373f22a.
This reverts commit faa114e.
This reverts commit 5a8dfad.

Conflicts:

	src/compiler/scala/tools/nsc/backend/icode/GenICode.scala
This reverts commit 892ee3d with
exception of keeping `@static` annotation in the library so we
can deploy a new starr that does not depend on it before removing
it completely.

Conflicts:

	src/compiler/scala/tools/nsc/backend/icode/GenICode.scala
	src/compiler/scala/tools/nsc/backend/jvm/GenJVM.scala
	src/compiler/scala/tools/nsc/transform/CleanUp.scala
Deployed a new starr that does not depend on `@static` annotation.
The next step will be deleting `@static` from the library
altogether.
@axel22
Copy link
Contributor
axel22 commented Sep 18, 2012

LGTM

@scala-jenkins
Copy link

Started jenkins job pr-rangepos at https://scala-webapps.epfl.ch/jenkins/job/pr-rangepos/499/

@scala-jenkins
Copy link

Started jenkins job pr-scala-testsuite-linux-opt at https://scala-webapps.epfl.ch/jenkins/job/pr-scala-testsuite-linux-opt/1207/

@scala-jenkins
Copy link

jenkins job pr-rangepos: Success - https://scala-webapps.epfl.ch/jenkins/job/pr-rangepos/499/

@scala-jenkins
Copy link

jenkins job pr-scala-testsuite-linux-opt: Success - https://scala-webapps.epfl.ch/jenkins/job/pr-scala-testsuite-linux-opt/1207/

gkossakowski added a commit that referenced this pull request Sep 18, 2012
@gkossakowski gkossakowski merged commit a9f95dc into scala:2.10.x Sep 18, 2012
@allxiao
Copy link
allxiao commented May 29, 2015

Hi, is there any further plan for this @static feature? It's been nearly 3 years since the reversion.

@lrytz
Copy link
Member
lrytz commented May 29, 2015

@lrytz
Copy link
Member
lrytz commented May 29, 2015

the issues discussed there are blockers imo.

@2xsaiko
Copy link
2xsaiko commented Apr 17, 2017

Did anything else ever happen after this discussion?

@jvican
Copy link
Member
jvican commented Apr 17, 2017

Yes @mrebhan. A SIP was created: http://docs.scala-lang.org/sips/pending/static-members.html. The SIP is under implementation since a member of the SIP board volunteered to provide one.

This implementation would in theory target 2.12.x.

@SethTisue
Copy link
Member

yes, see http://docs.scala-lang.org/sips/pending/static-members.html

plus it was discussed at a SIP meeting. ordinarily the minutes would be found at http://docs.scala-lang.org/sips/minutes-list.html, but I see that's fallen behind by some months — for now see scala/docs.scala-lang#762

@jvican
Copy link
Member
jvican commented Apr 17, 2017

I beat you by 1 minute and 37 seconds @SethTisue. You're not as fast as you used to be 😜.

@SethTisue
Copy link
Member

I spent the extra two minutes finding the minutes PR :-P :-P

@2xsaiko
Copy link
2xsaiko commented Apr 17, 2017

Thanks guys :'D

@Clyybber
Copy link

Any progress on this feature?

@NthPortal
Copy link
Contributor

As of 2.13.0/2.12.9/2.11.12 (the latest versions of each of the last three releases), Scala generates static forwarder methods:

// Test.scala
object Test {
  val foo: String = "foo"
  def bar: String = "bar"
}
// javap -c 'Test.class' # compiled with 2.13.0, 2.12.9 or 2.11.12
public final class Test {
  public static java.lang.String bar();
    Code:
       0: getstatic     #16                 // Field Test$.MODULE$:LTest$;
       3: invokevirtual #18                 // Method Test$.bar:()Ljava/lang/String;
       6: areturn

  public static java.lang.String foo();
    Code:
       0: getstatic     #16                 // Field Test$.MODULE$:LTest$;
       3: invokevirtual #21                 // Method Test$.foo:()Ljava/lang/String;
       6: areturn
}
// javap -c -p 'Test$.class' # compiled with 2.13.0
public final class Test$ {
  public static final Test$ MODULE$;

  private static final java.lang.String foo;

  public static {};
    Code:
       0: new           #2                  // class Test$
       3: dup
       4: invokespecial #14                 // Method "<init>":()V
       7: putstatic     #16                 // Field MODULE$:LTest$;
      10: ldc           #17                 // String foo
      12: putstatic     #19                 // Field foo:Ljava/lang/String;
      15: return

  public java.lang.String foo();
    Code:
       0: getstatic     #19                 // Field foo:Ljava/lang/String;
       3: areturn

  public java.lang.String bar();
    Code:
       0: ldc           #23                 // String bar
       2: areturn

  private Test$();
    Code:
       0: aload_0
       1: invokespecial #24                 // Method java/lang/Object."<init>":()V
       4: return
}
// javap -c -p 'Test$.class' # compiled with 2.12.9
public final class Test$ {
  public static Test$ MODULE$;

  private final java.lang.String foo;

  public static {};
    Code:
       0: new           #2                  // class Test$
       3: invokespecial #14                 // Method "<init>":()V
       6: return

  public java.lang.String foo();
    Code:
       0: aload_0
       1: getfield      #17                 // Field foo:Ljava/lang/String;
       4: areturn

  public java.lang.String bar();
    Code:
       0: ldc           #20                 // String bar
       2: areturn

  private Test$();
    Code:
       0: aload_0
       1: invokespecial #21                 // Method java/lang/Object."<init>":()V
       4: aload_0
       5: putstatic     #23                 // Field MODULE$:LTest$;
       8: aload_0
       9: ldc           #24                 // String foo
      11: putfield      #17                 // Field foo:Ljava/lang/String;
      14: return
}
// javap -c -p 'Test$.class' # compiled with 2.11.12
public final class Test$ {
  public static final Test$ MODULE$;

  private final java.lang.String foo;

  public static {};
    Code:
       0: new           #2                  // class Test$
       3: invokespecial #12                 // Method "<init>":()V
       6: return

  public java.lang.String foo();
    Code:
       0: aload_0
       1: getfield      #17                 // Field foo:Ljava/lang/String;
       4: areturn

  public java.lang.String bar();
    Code:
       0: ldc           #20                 // String bar
       2: areturn

  private Test$();
    Code:
       0: aload_0
       1: invokespecial #21                 // Method java/lang/Object."<init>":()V
       4: aload_0
       5: putstatic     #23                 // Field MODULE$:LTest$;
       8: aload_0
       9: ldc           #24                 // String foo
      11: putfield      #17                 // Field foo:Ljava/lang/String;
      14: return
}

lrytz pushed a commit to lrytz/scala that referenced this pull request Nov 5, 2019
This commit completes the abstraction over dependency kinds in the
incremental compiler, started with scala#1340.

Rewritten from sbt/zinc@649168e
@HyukjinKwon
Copy link

Scala 2.13 is out. How do we plan this?

@NthPortal
Copy link
Contributor

it's not obvious to me that there's still a need for this. given that the compiler already generates forwarders, what's your use case @HyukjinKwon?

@HyukjinKwon
Copy link

I would like to define an object that has a static field that can be accessed in Java as well, for example:

object Foo {
  val field = "abc"
}

and in Java side:

Foo.field

The reason is that to provide the consistent API usages in both Scala and Java. Does it make snese?

@NthPortal
Copy link
Contributor

as I mentioned, the compiler generates static forwarders that can be accessed from Java. please see the bytecode showing the static methods in my comment immediately above. while they are methods rather than fields, they still permit access from Java (and are generally considered better practice anyway).

@HyukjinKwon
Copy link
HyukjinKwon commented Sep 23, 2020

The point here is to have a field instead of a method in Java side in order to support the same shape of the APIs. I want to support Foo.field in both Java and Scala instead of Foo.field() in Java alone.

Just allowing a way to access is not enough in particular in APIs. For example, you cannot do such things:

object Nations {
  object Korea {
    def localize = ...  
  }
  val korea = Korea

  object US {
    def localize = ...      
  }
  val us = US
}

In Scala:

Nations.us.localize(...)

In Java:

Nations.us().localize(...)

@NthPortal
Copy link
Contributor

that's part of the Uniform Access Principle - that is, it allows you to swap a val for a def with no parameter lists and vice versa in a binary and source compatible way. while it will look different in Java, because they both are methods and use (), they remain source compatible when you change the implementation.

@HyukjinKwon
Copy link

So just to clarify, there's no way to make Java to call Nations.us.localize(...) like Scala does, and this reverted change fixed it. Is it correct?

@dwijnand
Copy link
Member

Correct, there's no way to define a static field in Scala. The proposal for that is SIP-30 (https://docs.scala-lang.org/sips/static-members.html) and it's "under review" but hasn't been discussed recently. I think it lacks both a motivated implementer and a SIP committee champion, at this point.

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

Successfully merging this pull request may close these issues.

0