2 ms·
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 a
by jwdunne 5y ago
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).
- captn3m0 5y agoI actually prefer auto-loading, which lets you iterate through a package manager much easier/faster - PHP iterated through PSR-0[0] before landing on PSR-4[1], and you can always build your own (which is what most frameworks pre-composer were doing). With Rails 7 and Zeitwerk, the Ruby community has landed on a very similar auto-loading system as PHP now[2] with constants translating to paths by convention. [0]: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md https://github.com/php-fig/fig-standards/blob/master/accepte... [1]: https://www.php-fig.org/psr/psr-4/ https://www.php-fig.org/psr/psr-4/ [2]: https://github.com/fxn/zeitwerk#the-idea-file-paths-match-constant-paths https://github.com/fxn/zeitwerk#the-idea-file-paths-match-co...
- jwdunne 5y agoYeah, I prefer an actual module system over PHP namespaces plus autoloader. It feels like a hacked on module system tbf. BUT I do get lots of real work done using namespaces and a PSR autoloader so it works. I do wish they would extend auto loading for standalone functions and constants though.