Registering project names on scala-lang.org

[oscar]

For us old folks who actually like the domain name as package space, what about keeping a database of packages at scala-lang.org so we could use that:

org.scala_lang.somethingawesome

This gives a pretty short name, that is still namespaced in a way that avoids collisions*

• note, sadly scala-lang has a - which is not legal, so perhaps someone could have org.scala_lang in the future.

[larsrh]

How should that work? Some web interface where you can claim a name? Should that come with publishing rights on Sonatype somehow?

[jvican]

Hey @oscar, good to see you around!

@oscar

For us old folks who actually like the domain name as package space, what about keeping a database of packages at scala-lang.org so we could use that:

org.scala_lang.somethingawesome

I didn’t understand your suggestion. Do you want to be able to register names on the Scala namespace? If so, what’s the reason?

[Blaisorblade]

@jvican

I didn’t understand your suggestion. Do you want to be able to register names on the Scala namespace? If so, what’s the reason?

@jvican To make package names globally unique on the JVM and prevent accidental collisions, it’s recommended to start package names with (reversed) domain names—so that the DNS system functions as a global top-level registry. People used to actually stick to such rules, especially in Java and in Eclipse—and Eclipse seems big enough that you’d get actual problems otherwise.

So if Google creates JVM package com.google.guava, there’s no chance somebody outside Google also creates com.google.guava. Somebody inside Google could, but it’s assumed an organization can prevent collisions internally—for instance via some sort of registry like @oscar suggests!

May I ask if this should be an optional Scala Platform benefit, or is this a derailing of the original proposal?

[jvican]

@Blaisorblade

To make package names globally unique on the JVM and prevent accidental collisions, it’s recommended to start package names with (reversed) domain names—so that the DNS system functions as a global top-level registry. People used to actually stick to such rules, especially in Java and in Eclipse—and Eclipse seems big enough that you’d get actual problems otherwise.

Yes, I am familiar with this. What I don’t understand is why Oscar wants to have access to the Scala namespace or a Scala-owned namespace for contributors. Can you elaborate @oscar?

@Blaisorblade

May I ask if this should be an optional Scala Platform benefit, or is this a derailing of the original proposal?

This has been discussed in depth here:

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.

You can read that thread for the context. To answer your question more directly, no @Blaisorblade, the Scala Platform won’t have a common namespace.

[jvican]

@som-snytt

I’d go for a “scalang” prefix to announce “I favor a scala API and probably you’ll never call me from java or groovy”.

I really like scalang, but I see no reason why we should provide this namespace to open source developers. I hope Oscar elaborates on this point. On my side, I may even use it for the Scala Platform.

[easel]

@jvican

I see no reason why we should provide this namespace to open source developers.

I think the issue is that getting a “real” domain to back a given package is potentially costly and a hassle to maintain. “io.github.xxx” packages tend to be unstable while their ease of acquisition makes them increasingly common.

If scalang.* could be used for packages that meet a certain bar wrt. permanence it might help those packages to grow and stabilize.

[sarahgerweck]

A domain costs about $1 per month, and a single domain can be used to host all the projects you maintain. If you’re just using ownership to own a code namespace, the only maintenance required is to make the payments and keep your address updated—and nobody actually polices the latter.

There are doubtless some developers out there for whom $1 / month is hardship, but I don’t think that’s something for which people need to optimize, especially since there are a number of free alternatives already mentioned like io.github.