Replace static forwarders by a non-$ method to get the module

[lrytz]

While fixing the issues with static forwarders, @retronym suggested we should stop emitting those forwarders and instead emit a single static method to access the companion module.

Proposal:

1. Add the static method in 2.13 (object A generates public static A$ module() { return A$.MODULE$ } in class A)
2. Deprecate static forwarders - in 2.13 already?
3. Remove static forwarders - in 2.14 already?

Opinions? Did we discuss this before?

[SethTisue]

I don't recall this ever being proposed before.

I'm rather hesitant about this change. (Maybe I need time to get used to the idea, since it's new to me.)

If we want to make a change in this area, I would suggest not deprecating and not removing, but making them opt-in via a compiler flag. But even that, I'm hesitant about. I think we'd need to discuss it on https://contributors.scala-lang.org and see what the community thinks.

I used static forwarders all the time when I worked on a large mixed Java/Scala codebase. It's one of the features that makes it not just possible, but convenient for Java users to start sneaking Scala code into mixed codebases, or to write Scala libraries that are usable from Java without annoying the Java clients with extra ceremony.

Making the forwarders opt-in would reduce the harm in those scenarios, but it wouldn't remove it, because what if you don't control the Scala code in question, you have to ask the author to enable the forwarders, if it isn't the default.

What about making the forwarders opt-out, so there's an escape hatch in cases where they're getting in the way? Thinking out loud.

[SethTisue]

Also, I've never been personally been bitten by a static forwarder, I haven't personally experienced the downside. In order to justify the change to the community, I think you and/or Jason would need to be explicit about what the downsides of forwarders are.

[lrytz]

I've never been personally been bitten by a static forwarder

you and/or Jason would need to be explicit about what the downsides of forwarders are

You might be on the right track here: these forwarders are a bit annoying from our perspective, selecting the right methods is a bit of a struggle. So maybe they look worse with the compiler writer's bias.

[SethTisue]

one further thought: we might ask within Lightbend if the static forwarders are considered valuable by Akka, Play, Lagom, etc, they're the biggest users of Scala-for-Java-consumption

[lrytz]

Good idea. cc @patriknw, @marcospereira, @ignasi35. To summarize, currently object A { def f = 1 } generates (approximately)

class A$ {
  public static A$ MODULE$ = new A$;
  public int f() { return 1; }
}
class A {
  public static int f() { return A$.MODULE$.f(); }
}

So Java clients can write A.f(). The proposal is to only emit a single static method in A, so java clients would have to write A.module().f().

[SethTisue]

You mean A.module().f()? (static "method"?)

[lrytz]

right, fixed!

[patriknw]

@lrytz We use A.f() all the time in Java APIs. Having to use A.module().f() is not an option in my opinion. That would be very inconvenient and leaking a technical Scala detail into user api.

[dwijnand]

It's common in Java to have a static method or field to access the instance of a singleton, like:

Foo.INSTANCE.doThing();

(There are various implementations for singletons in Java, I think Effective Java explains them).

In Akka there seems to be some precedence of defining getInstance for Java users.

For true static methods, for Java or other reasons, SIP-30 is relevant:

https://docs.scala-lang.org/sips/static-members.html

[dragos]

Would this single-out main and still emit a static forwarder for this one?

[SethTisue]

@lrytz shall we close this?

[retronym]

Yeah, seems like this isn't really feasible.