Scenario: An open-source PHP project that has existed for several years has too many classes in the main namespace that we want to refactor some of them into another namespace, but we have a widely used and diverged plugin API, and refactoring may cause a major backwards incompatibility. This plugin API is basically loading external PHP files that interact with the classes and functions in the core code.
This project is not a Composer project (don't ask why), and it uses an class autoloading library maintained by ourselves.
I recently discovered the function
class_alias, which might help with this problem.
I am considering refactoring the classes in the main namespace into a sub-namespace, and update references to them in the project. For the PHP files that originally contained the refactored classes (now they have been moved), I want to put something like this:
<?php class_alias(NewClassName::class, OldClassName::class);
This will be loaded by the autoloading library when a plugin requires the use of OldClassName. I have tested this method and primary tests show that it works well.
Next step is to clean up the main namespace directory to fulfill the real motive of our refactoring - there are too many files in the main namespace directory. Hence, I am creating a new directory next to the source directory called
als (alias directory), and making
als a secondary source folder where alias class files are located.
Before, the project looked like this:
Now, the project looks like this:
src/ src/Foo/Bar/Bar.php als/ als/Foo/Bar.php
Tests show that this method is working well so far.
However, are there any possible side-effects, from technical/performance perspective, documentation perspective or code structure perspective? We have never tried doing something like this and have never seen anyone doing this. Many developers are watching the repository for reference of the API, so we want to be more careful before trying these changes.