This is roughly PHP’s approach. In this case, Illuminate is the vendor prefix and Mail is the package name. This often but not always corresponds to the rules around the composer package name, which would be illuminate/mail in this case.
This is similar to NPM’s organisation prefix (@foo/bar).
But yeah, I’m not defending the hacky way namespaces are resolved through autoloading. I do prefer actual language support for a module system (but Ruby suffers from this problem too).
If your namespaces are more than three segments deep then I believe you may be doing it wrong. This is nothing implicit to the way namespaces work in PHP, it's just bad design. Most Composer packages i've seen only go as deep as vendor\package\whatever anyway. That's not difficult.
Composer autoloading and the PSR-4 naming convention works just fine, since you have to separate the class names with some kind of information about the developer, followed by the name of the class. Java uses a similar naming scheme too ("org.apache.commons.SomeClass" etc.) though autoloading is specific to PHP.
I'm curious as to why you consider autoloading over PSR-4 namespaces as insufficient.
I thought the point of autoloading was to make things easier, not to replace require_once with something more verbose. Why should I have to import classes from within my own package?
We actually keep pretty close to that, but have two implementational differences:
1. Namespaces are linked to a specific directory instead of just translated to a path
2. Our paths are fully lowercase
And I stand by those. The first allows for more flexibility when it comes to code organization and the second makes mistakes in classloading a lot less common. You can disagree with these but we have documented them clearly. Also it's quite easy to add another autoloader, ours won't even do a filesystem check when trying to load from an unknown namespace so it should add hardly any overhead to attach a Zend (or anything) compatible loader.
True, although it gets annoying having to "rename" a package like this. If it's a package you use everywhere in your project, it gets old fast; canonical, author-defined names are always the best option.
To me the problem solved by namespaces is making it clear what's an official package of a project and what's a non-malicious third party package intended to work with that project.
e.g. bevy and amethyst have claimed a load of crate names like bevy-x or amethyst_y because they thought they might release an official addon to their framework to handle those areas. e.g. bevy did it with this https://github.com/bevyengine/bevy-crate-reservations/blob/m... and amethyst did it the long way as far as I know
Organisations wanting to have consistent package names and users wanting to identify related packages are smaller problems than the "all the good names are taken" and "packages can impersonate other packages with typos" problems.
Im sorry but accepting underscores as a valid alternative to namespaces in 2012, is not a "best practice".
The whole concept of PSR-0 is ridiculous anyway, because PHP supports registering multiple class loaders. If a project wants to use a naming convention that won't work with standard spl_autoload(), they can register their own autoloader.
Modern package registries implicitly treat all package authors as equally trustworthy—you don't need to know which organization wrote the `zip` package, you just need to know that there's a package by that name and it opens your zip files. It's charmingly egalitarian and quite convenient, but the global namespace both enables typosquatting and trains developers to not think at all about the people who write the stuff in their supply chain. The biggest point of failure in any system—the humans—has no first-class expression in the typical modern package registry.
I can't help but wonder if this is something Maven got right. Namespacing packages according to domain names makes typosquatting vastly more difficult to pull off and makes authorship of dependencies a first-class concern for end users. If something is under org.apache, that means something about the contents of the package, and PyPI and company don't front that information nearly as well as Maven does.
> Yet to see any proof that namespacing has made things better in other ecosystems
It's really as simple as this: many libraries are generic enough implementing something that already exists. Let's say you want a library to manage the SMTP protocol. On crates.io, of course someone has already taken the "smtp" crate (ironically, this one is abandoned, but has the highest download counts, because it's the most obvious name). Let's say you disagree with the direction this smtp crate has gone, and you make your own. What do you call it?
Namespaces solve this problem. You'd instead of have user1/smtp and user2/smtp competing in feature sets. You can even be user3/smtp if you don't like the first two.
This is precisely what Java enables too. The standard library is in com.java.*; if you don't like how the standard library does something, you can make com.grimburger.smtp and do it yourself. If you choose to publish to the world, all the more power to you. It doesn't conflict with the standard library's smtp implementation.
The autoloading basically fixes this, at least insomuch as you use the namespace that you want rather than require a file.
Of course, you need an autoloader, and writing one is complicated enough that you'll want to use a pre-existing one, which means sticking to whatever conventions it uses for storing modules in the filesystem (probably a PSR), but realistically you're going to want to do this anyway.
So yeah, it's more complicated than it needs to be but on the upside it's a lot more flexible too; you can pretty much define whatever naming convention you can think of.
It's a lot easier to typo a package (e.g. requests -> request results in the wrong package) than it is to typo a namespace-package (@namespace/requests -> @namespace/request would result in an error).
Somewhat likewise, namespaces can build trust in a way that single packages can't
The main thing I disagree with you on, is that there is a namespace collision because of the package manager, or that there is a namespace collision because both use Rust. If there is a namespace collision, it should be because they're both tools used by developers. The package manager issue is solved easily by adding something to the package name. As for the language, Rust is shaping up to be more like C++ than Ruby or Python, where the main community is more about the language and the standard library and less about the myriad different uses of it.
Great idea except you don't namespace anything! I like namespaces because one library or css import from another won't ever stomp on each other. I've seen 'ui', 'button' and 'red' in several other packages and places. They're going to conflict. The one with the greatest specifity is going to win and cause untold hours of frustrating debugging.
I can understand not liking it, but I don't understand why you find it strange: global namespaces are the norm in language package distribution. RubyGems, NPM, PyPI, and Crates all use flat namespaces (either by default or as their only supported mode).
Namespace partitioning has advantages, but it also doesn't solve squatting problems on its own: anybody (or any process) that's fooled by `requests` vs `pyrequests` is also going to be fooled by `some-owner/requests` vs. `requests-org/requests` (the latter being the fake one).
This is similar to NPM’s organisation prefix (@foo/bar).
But yeah, I’m not defending the hacky way namespaces are resolved through autoloading. I do prefer actual language support for a module system (but Ruby suffers from this problem too).
reply