Am 13.02.2016 um 10:41 schrieb Bardur Arantsson:
It's terrible and basically name-space only.
That's just "do one thing, and do it well". Or, conversely, "just the namespace, look elsewhere for what you think a module system is". I guess the worst problem with SML's module system is that it does so many thing all rolled into one.
What's even stranger is that it's an *open* namespace (apart from the standard ones, I believe?) which means that I can retroactively add a class in say,
org.spring.integration
and access package-scope bits of the original org.spring.integration namespace.
Yes, but you get into all sorts of trouble when packaging, and all kinds of tools will detect that and your software will be seen as low-quality. Also, you can't do this unintentionally, so it's not a source of bugs. So while possible in theory, it does not happen in practice unless in the most dire circumstances, and even then it's not the workaround people choose because it's too painful.
It's a pretty weird system that seems to be driven by Java's "one-class-per-file" mentality[1].
Nah, that's unrelated.
Disclaimer: Java 9 is getting a new module system, Jigsaw, but I'm not really too familiar with what it actually does, so I won't comment beyond this disclaimer :).
Jigsaw is about the ability to define large-scale modules. I doubt it's a good approach, but I guess I'll work with it and see whether that's really going to be the case. The Java culture isn't so much about good theory but about good engineering, so it's quite possible that my fears are unfounded.
The only thing that sets Java apart is that the DNS namespace is used as the basis, and that's not even a language rule, just a recommendation; the fascinating thing is that a mere recommendation was enough to make clear who's responsible for fixing a name conflict, and virtually eliminate name conflicts from the Java world.
Yes, *this* was a FANTASTIC idea and it's soooo simple once you're aware of it. (No sarcasm intended, btw.)
Agreed, but if you were designing a language in the pre-Java times, the DNS was not the global registry where every programming-related entity would have a globally unique name. Most companies didn't even know what a domain name is, let alone have it registered. Java went public roughly at the time that the Internet^W^W HTTP took off, and I suppose the idea to use domain names as the global namespace was more of a lucky accident because the plan was to make Java the Lingua Franca of browser scripting, and they *had* to have a way to make all those dynamically-loaded modules coexist, and in the WWW, the domain names come naturally. Had Java been planned to become the server language it is today, I doubt they'd have had that idea.
Unfortunately, the Scala people seem to be tiring of the long names and are regressing towards just using top-level names like "play" and "argonaut" and such... :/
I think that's mostly exceptions for the really-well-known frameworks. Similar to the "java.*" and "javax.*" namespaces. I can understand why they prefer "play.*" over "com.playframework.*", but I don't really get why they say "argonaut.*" instead of "io.argonaut.*". Weird. OT3H it's not a really serious problem. The DNS as namespace means you have a spot that's guaranteed to be free for your code, and as long as nobody uses a TLD for his package root, it's all fine. Things could become ugly for the Play framework is somebody registers "play" as a new TLD. It would be a clearly a problem for the Play framework, not for the DNS, so at least the responsibilities for fixing the problem will be easy to assign. Or maybe the Playframework guys will get a chance at reserving whatever .play domains would collide with their package names, it's quite possible they'd get heard during the sunrise period of a hypothetical new .play TLD. So... things will muddle through as usual, and the main benefit is that you can choose a DNS-based spot in the namespace and be guaranteed that nobody else can usurp it because you registered that domain. And if somebody publishes code in that part of the namespace anyway, they will get labelled as "misleading" or even "abusive" and will be forced to move elsewhere.
[1] Yes, I'm aware that you can actually have multiple classes in a file. Almost nobody does that.
It's mostly useless because you cannot have multiple public classes in a file, the other classes need to be package-private. And almost nobody uses package-private because the visibility rules around that are complicated, i.e. it is almost never what you want and also bad for maintenance.