On 25 November 2013 07:45, Sean Conner <sean@conman.org> wrote:
What about organizational prefixes don't you (that is, Pierre, not Dirk)
don't like about such prefixes?
I'm neither Pierre or Dirk, but I can tell you what I don't like about them: organizations change.
All the Java libraries are now tagged with organizational prefixes for a company that no longer exists. This is especially egregious in cases like the Sun Game Server … I mean Project Darkstar … I mean the RedDwarf Server. The RedDwarf Server is replete with APIs falling under the com.sun.* hierarchy as well as its own APIs and the APIs of Darkstar, all scattered around various organizational prefixes depending on the whims of the people who added whatever new feature.
It's an unholy mess.
I've never seen non-trivial uses of organizational prefixes that didn't result in the same unholy mess.
Now let's consider your case of using organizational prefixes. "org.conman.foo" certainly falls under the heading of unique. Until you let your domain name lapse (for whatever reason) and it belongs to someone else. Or until you let the project lapse and someone else takes it over. Indeed let's take a look at simple forking.
Let's say you make 'org.conman.foo' as a module. You make a good package everybody uses and then move on. Someone wants to add new features but you don't really want to work on the module any more. The F/OSS thing happens and your package is forked. The new functionality is added. Note: added. Not otherwise changed. 99.44% of the code is exactly the same. It just added "baz" access to your already-provided "bar". Anybody who wants to use what is essentially a drop-in replacement library, except for that one added feature, now has to edit all their source code to change 'org.conman.foo' to 'biz.buzz.foo' even if most of their code isn't using the new functionality. (It's either that or you'll be pestered with questions about the new functionality you had nothing to do with until Hell freezes over.)
Yes, there has to be a way to distinguish between your package and the forked one. No, however, I don't think organizational prefixes on the module names are the way to do it. What we need is, perhaps, a more robust way to locate packages than merely by name; some kind of searchable and runtime-verifiable package metadata.
-- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
