So glad someone wrote this. In PHP - I absolutely hate having to work around autoloaders in third party APIs. I love structuring my imports exactly around the directory structure I design; some project-specific code in /services/ can always call something in ../util/ or a static in ../const/ or a pseudo-global function in ../fwk/ just as I, the designer, intended. And if one of those should break as I structure a new project, any old IDE will notice and highlight it. If something has to be put in some weird directory structure, doesn't matter; I don't consider these imports to be anti-DRY, they're the linkages. You don't want to leave them out of the code.
DRY is for logic, not linkage. Linkage is a necessary part of sharding your logic into intelligible and discreet modules, packages or classes. The linkages between those must be obvious for anyone who comes along and reads your code later.
In PHP, everything can be configured with composer, PHP's defacto package manager, including all your directories and their namespaces.
> I absolutely hate having to work around autoloaders in third party APIs.
If your "third party API" aren't using composer themselves, a defacto standard in PHP, then they are not professionally written.
PHP doesn't have modules or any form of modularity or packages, unlike Ruby. PHP only has direct file references from other files (include,require...) and SPL autoloading which is just a way to automate direct file reference (through namespaces or other techniques).
I'm not sure what PHP autoloading has to do with any of this article at first place.
For the love of God or Atheismo, stop making these kinds of ass backwards structures the rest of us have to deal with when a legacy project gets dropped on our desk..
There's an established pattern that works across all projects, psr-4, use it.
I don't really see the practical difference between what I'm saying and doing it with Namespace\Subnamespace\ClassFile. The code I write anyway is PHPDoc'd and easily linkable as long as it's kept in the designed file hierarchy. [edit: Yes, I use folders and not normally namespaces for organization in my PHP projects, in part because many of them have been steadily maintained since PHP 4].
What I'm objecting to are "autoloaders" that allow "packages" to register in a way that makes it difficult to follow code. Things like Square's API which includes at least a dozen PHP files called things like "Autoloader.php", "autoload.php", "bootstrap.php", etc, each with their own unique twist on if (file_exists($file)) requre($file).
DRY is for logic, not linkage. Linkage is a necessary part of sharding your logic into intelligible and discreet modules, packages or classes. The linkages between those must be obvious for anyone who comes along and reads your code later.