Thanks for the proposal!
I will however say that I’m against this proposal because of it’s oversimplified view on the problem and lack of specific actionable and specific this-is-what-that-would-gain-at-that-and-that-cost points.
Providing a single namespace that covers 99 % of common use-cases allows the Scala platform to evolve at its own pace.
As someone participating in a standardisation ( reactivestreams.io ) process over the last years, I can tell you even agreeing on an API that has a total of 7 methods, and a specific goal, by definition, took years to reach agreement and mind-share. The “99% use-cases” phrasing makes me very nervous as it shows that while the proposal has a lot of good intentions, it does not seem to be backed by investigation in what realizing such effort would take – by which I mean, it’s a huge undertaking, with questionable benefits, and some things would end up leaking though anyway.
Coming back to the problem statement though:
This makes it unclear to user and library author alike whether or not a compiler backend (JVM / JS / Native) implements the desired JDK artifact.
This might be true, however the way this information would have to be relayed to users would in any case have to be on a projects website or repository, that “we work on … runtime”. Which isn’t very different from now.
I also don’t believe that libraries should be encouraged to claim “we run on X” without ever testing against that runtime. Yes, building a project for multiple runtimes does carry a cost for maintainers of testing against those runtimes, and I don’t think it should be encouraged to “yeah you don’t have to test because you use the … namespace!”.
As a thought experiment, we can also challenge my above statement that the “safe namespace” does not provide real safety – since runtimes differ. In such thought experiment, we can say that we only use “the safe namespace”, and are therefore proven to work on “all” runtimes… This sounds fine, but… then we need a way to guarantee that some project did not accidentally use the “not safe namespace”, and how would we do that? Either we need to implement a strong encapsulation (basically reinvent JDK’s modules, and enforce them in Scala). Such module system exists, and support for it should/will happen in Scala in any case, but that’s JDK-specific, since the runtime enforces it as well. The alternative is that library authors need to watch out and document things (so we gained nothing again, as it’s back to documenting things).
So IF we were to pursue what this proposal calls namespaces, it would have to align and play well with JDK modules, and enforce the same rules in other runtimes… But the other runtimes do not have such mechanisms, and there would be a semantic mismatch there again, so I don’t think this is a good idea to force others to implement the JDK module system – it’s complex, and other runtimes simply don’t have that nor should we force the JDK things on them.
Which comes back to the point of – yes, the runtimes do differ, and just blessing names, without a strong encapsulation tooling provides no more value than active testing on runtimes that a library claims to be compatible with. Rather even, without strong enforcing of such modules, it would even give a false perception of safety, which is more dangerous than no such (false) perception and reliance on testing (which always should be in place anyway).
My writeup has gotten a bit long, but I hope I’ve exemplified some of the issues that I see with the proposal.
Many of the goals of this proposal are achievable without the “namespaces”, and testing is required in any case to pull such things off in the real world.
Hope this helps,
[ Akka, Scala Platform Process ] Member