4 ms·

> What's the difference between `google.golang.org/protobuf` and `org.golang.google.protobuf`? There isn't one, because that's also a (mangled) URL, namely "ht

by a1369209993 6y ago

> What's the difference between `google.golang.org/protobuf` and `org.golang.google.protobuf`? There isn't one, because that's also a (mangled) URL, namely "http://protobuf.google.golang.org/" http://protobuf.google.golang.org/", and should be rejected for the same reasons. A identifier would be "protobuf"; note the lack of any reference to the DNS domain.

grey-area 6y ago
Do that and soon you're going to have to introduce namespaces, and you're back to something that looks like urls. People use these longer import identifiers because they avoid polluting the global namespace, which be reserved for very important packages (in the case of go the std lib).
- munificent 6y ago
  > Do that and soon you're going to have to introduce namespaces Everyone says this but there is strong evidence from npm and other package ecosystems that you can go surprisingly far with a single flat global namespace. I think there is a paranoia among software developers about potential name collisions. But in reality, name collisions are rare and easily avoided. There are 308,915,776 unique six-letter identifiers. Go to eight and you have 208,827,064,576 names to choose from.
  - a1369209993 6y ago
    > There are 308,915,776 unique six-letter identifiers. Go to eight and you have 208,827,064,576 names to choose from. To be scrupulously fair, no one wants to name their package "udjwhc"; the problem is more "protobuf" (by google) vs "protobuf" (by someone other than google), both implementing similar but subtly different interfaces for doing the thing they're named after.
  - grey-area 6y ago
    Namespaces are used for clarity (this is pkg log from org/user x), not because we run out of letters.
    - munificent 6y ago
      The problem with that is that you're essentially using a hierarchy to attach some piece of metadata to each package. The question then is what piece of metadata is both so valuable to be worth enshrining in the name and yet so unchanging that if its value changes, you're OK with every user of that package having to migrate to the new identifier. I have yet to see any particular bit of metadata that fits into that set. Using "owner" like you do in your example here is a common choice, but also very frequently changes. If you look around, you'll find lots of examples where a package moved to a new owner and caused all sorts of problems because now all the old name references no longer work. You could try to pick some essentially descriptive property of the package itselfs—maybe, say, "Net" if it has to with networking—like CPAN does, but it's not clear that doing so adds any real value beyond satisfying our human desire to put things in neat littly cubbyholes.
      - grey-area 6y ago
        I do have some sympathy with your views on this. Package identifiers don't have to live in a hierarchy or include origin/owner. That they do in so many systems indicates people find this information useful. I do disagree that owner changes frequently - for the vast majority of packages that's not the case. Personally I find knowing the owner sometimes useful, and quite like the use of urls in go imports as it also lets me look up the source. I've never found it a huge problem (and I have moved packages from one place to another a few times).
  - tmzt 6y ago
    Of course, npm did eventually introduce a second level of namespacing, in the form of scopes (such as @ansible or @vue). Unpaid package hosting is still limited to one level.

grey-area 6y ago

Do that and soon you're going to have to introduce namespaces, and you're back to something that looks like urls. People use these longer import identifiers because they avoid polluting the global namespace, which be reserved for very important packages (in the case of go the std lib).

munificent 6y ago
> Do that and soon you're going to have to introduce namespaces Everyone says this but there is strong evidence from npm and other package ecosystems that you can go surprisingly far with a single flat global namespace. I think there is a paranoia among software developers about potential name collisions. But in reality, name collisions are rare and easily avoided. There are 308,915,776 unique six-letter identifiers. Go to eight and you have 208,827,064,576 names to choose from.
- a1369209993 6y ago
  > There are 308,915,776 unique six-letter identifiers. Go to eight and you have 208,827,064,576 names to choose from. To be scrupulously fair, no one wants to name their package "udjwhc"; the problem is more "protobuf" (by google) vs "protobuf" (by someone other than google), both implementing similar but subtly different interfaces for doing the thing they're named after.
- grey-area 6y ago
  Namespaces are used for clarity (this is pkg log from org/user x), not because we run out of letters.
  - munificent 6y ago
    The problem with that is that you're essentially using a hierarchy to attach some piece of metadata to each package. The question then is what piece of metadata is both so valuable to be worth enshrining in the name and yet so unchanging that if its value changes, you're OK with every user of that package having to migrate to the new identifier. I have yet to see any particular bit of metadata that fits into that set. Using "owner" like you do in your example here is a common choice, but also very frequently changes. If you look around, you'll find lots of examples where a package moved to a new owner and caused all sorts of problems because now all the old name references no longer work. You could try to pick some essentially descriptive property of the package itselfs—maybe, say, "Net" if it has to with networking—like CPAN does, but it's not clear that doing so adds any real value beyond satisfying our human desire to put things in neat littly cubbyholes.
    - grey-area 6y ago
      I do have some sympathy with your views on this. Package identifiers don't have to live in a hierarchy or include origin/owner. That they do in so many systems indicates people find this information useful. I do disagree that owner changes frequently - for the vast majority of packages that's not the case. Personally I find knowing the owner sometimes useful, and quite like the use of urls in go imports as it also lets me look up the source. I've never found it a huge problem (and I have moved packages from one place to another a few times).
- tmzt 6y ago
  Of course, npm did eventually introduce a second level of namespacing, in the form of scopes (such as @ansible or @vue). Unpaid package hosting is still limited to one level.