Should the Scala Platform modules use the Scala namespace or a common namespace?

do you want the Scala Platform to use scala.*, not something like scalax.*?

My understanding is that the scala namespace is owned by EPFL and platform modules will not be re-rooted. I think it would be a poor idea to do so. Users need to understand what’s part of the core language and what isn’t.

3 Likes

We haven’t discussed yet, but there exists the possibility that they will be re-rooted under something similar to scala.platform. I’ll bring this up in our next meeting. My personal opinion is that that users of the Scala Platform have a clear idea of what’s part of the language and what isn’t – they have to add/choose a Platform in their build (not like the standard library that in any Scala installation is accessible).

2 Likes

there exists the possibility that they will be re-rooted under something similar to scala.platform

This seems like a very bad idea.

  • It makes Scala Platform modules clearly privileged above other libraries via access to the otherwise closed scala namespace. This will be divisive.
  • It implies a level of consistency that the platform cannot provide. Problems in the platform will be interpreted as problems with Scala itself.
  • It introduces a purely cosmetic breaking change to every library, all of which have “widespread adoption” already by definition.
7 Likes

That’s a good point — IIRC people were debating technical solutions to avoid breakage.
The advantage is if the Scala Platform is more adopted than modules — which seems be likely for beginners.

Makes sense, especially considering other platforms. Should the Scala Platform get a proper name to use in imports?

Not sure what you mean, but I think it might depend on what the “UX” is (how people actually consume the platform), which is another whole discussion and I don’t remember it being resolved.

Sorry for the unclear wording. To clarify: I expect the Scala platform might be adopted more than some of the libraries that join it — I’d guess more people are going to know about the platform than about better-files. And (IIRC like others) I expect that to matter more for beginners.

You might be right about the UX, but “more adopted” is still an expected consequence of stated goals; the UX should be designed to this end. IIUC, a goal is to get some advantages of a more “batteries included” standard library, without requiring LAMP to maintain it (which doesn’t work). If we quote https://scalacenter.github.io/platform-staging/platform.html we get something vaguely similar:

The Scala Platform is a stable collection of libraries with widespread use and a low barrier to entry for beginners and intermediate users.
Through a collaborative and meritocratic development process, the Scala Platform provides a smooth and productive programming experience right from the start, both for learning purposes and production use.

But catering to beginners might suggest a better UX than discussed till now… EDIT: forked off a thread on this direction.

I feel strongly that going forward, only the core standard library should stay in the scala._ namespace (or any of its sub-namespaces).

It’s unfortunate that modules like scala-parser-combinators are already in that namespace, but I think that is a historical accident, stemming from the standard library’s bad old kitchen-sink days, and doesn’t qualify as a precedent for our current choices. (We should be looking to move those modules out of scala._ space, even.)

tpolecat has already covered most of the main reasons for my opinion. I second his points.

Also, it hasn’t been explicitly been pointed out, perhaps because it’s something we all already know, but scala._ is imported by default into every Scala program. This is a major reason it is so privileged and a major reason we should be very conservative about introducing anything into it.

By contrast, in Java, only java.lang.* is automatically imported, not all of java.*. Things are different in Scala because we have nested packages and Java doesn’t, but that difference means we need to be more conservative than Java about namespace real estate, not more liberal.

8 Likes

I have also step forward and say that I agree with this statement. At least, it shouldn’t be required to reroot libraries.

About the scala._ namespace, I tend to agree with @SethTisue. But I guess what @jvican is striving for is some sort of namespace for the Scala Platform that platform libraries could move to if it would somehow be beneficial to them.

So I guess the question is, if putting stuff in submodules of the scala namespace is out, what namespace could the Scala Platform have, for the module authors that want to be part of some kind of Scala Platform namespace?

platform._ ?
or even the more verbose platform.core._
or the more explicit scalaplatform._

A Platform package doesn’t make any sense.

Why? Because we all agree that there can (and should) be alternative platforms. But there is no reason that one library cannot be part of two, or more, platforms! In that case, if each platform has its own platform package, that library cannot exist. Conclusion: it doesn’t make any sense.

it doesn’t make any sense

agreed

1 Like

As @heathermiller said, no one will be forced to choose a platform namespace, but for those who’d like to, a specific convention can be made available (if it makes sense).

If a library is part of more than one platform, the author would choose the package he prefers.

Platform packages can be just conventionally defined so that each platform can have his own variation, such as:

  • platform.generic._
  • platform.lightbend._
  • platform.typelevel._
  • platform.scalaz._

Personally I have no position on the subject, I’m just contributing to the discussion

1 Like

I like this idea. If there is no unifying theme, there is no platform. Lightbend and TypeLevel seem like two great examples of platforms to me.

That would get really awkward when a library was introduced into a ScalaCenter platform, changed its package to platform.scalacenter._ and was then also included into the lightbend platform (or any other combination)

More suggestion for codenames for the platform.
alasca (jumble of scala + a).
std, so it can be similar to C libraries. std.io for better-files.

I don’t see a clear advantage for library authors in exploiting a standard platform package naming.
After considering the criticism moved against the introduction of such package and the fact that no one is trying to actively defend such proposal, I would consider this topic closed.

(this issue seems already settled, but regardless:)

I thought of a consideration that hasn’t been mentioned. If you’re in scala namespace, you have access to things which are declared private[scala]. Allowing this violates modularity. When we’re maintaining the standard library, we would like to be free to refactor things declared private[scala] without worrying whether we’re breaking things that are somewhere else, in another repository entirely, maintained by different maintainers.

5 Likes

All your comments and suggestions make sense. Thank you for pointing them out. At this point, I’m pretty sure that putting the Scala Platform under the scala namespace would not bring us any benefit.

These are my propositions for alternative namespaces:

  • org.scala.lang.platform – named after the existing Scala Platform proposal website.
  • platform.scala – named after the suggestions in this thread (@pagoda_5b) . I like it because it’s short and to the point.

What do you guys think about them? You would get better files by including platform.scala.nio | org.scala.lang.platform.

I think the unifying prefix of platform in the namespace is nice.

I don’t think scala-lang translates to scala.lang. Maybe make it one word,
like scalaplat or something? Or just platform?

Also to be clear, what will be the naming convention outside of code for
this platform vs. other platforms?

Then maybe scalang :wink: