I saw an article on the namespace and decided to share the experience of translating existing projects to the namespace.
Basically, the article will be useful to those who have not yet used the namespace, but are thinking about rewriting the existing code.
I translated into the namespace several of my projects that were interconnected. The projects are not too big and I made the whole transition over the weekend.
The transition itself does not present any particular problems, below I described the sequence of necessary actions, which for the most part represent a routine and there is an opportunity to automate most of the work ... but as they say, the devil is in the details.
')
Sequencing
What needs to be translated: classes, interfaces, constants, functions.
What we are looking for in the code: define ('{CONSTANT_NAME}'), class {CLASS_NAME}, interface {INTERFACE_NAME}, function {FUNCTION_NAME}.
Next, we draw up a table where we bring in all our entities, the ads of which we found in the previous step. Add the required namespace in the declarations of all entities.
Next we go through the code and change the calls of the entities from the table, add the necessary namespace to the call, provided, of course, that the calling code has a namespace different from the entity.
Actually this is the main and most obvious part ends.
If you have an autoloader, then you need to teach him to recognize the namespace of the loadable classes.
If your code is covered with tests, run them and catch errors as you run the tests. If there are no tests, then the migration for you is complicated at times, at least you will have to test the code with your hands, because then you need to follow a few more steps.
What else should be changedBy declaring a namespace, you break a call to global entities, for example, if your code executes a "throw new Exception", then when you enter a namespace, such code will break. You will need to change the code to "throw new \ Exception", because the Exception class exists in the global namespace. You can go through the code in the search for the following structures:
new class, class :: method, extends class, implements interface, etc.
In the previous steps, we compiled a table of declared entities and then searched for their calls by code. If your code contains constructions of the form:
<?php
$class = 'Foo';
$class .= $bar;
$instance = new $class();
?>
then, accordingly, such code must also be found and changed, the previous steps will not fix it.
Separately, it is worth highlighting the problem of a “serving” code or a specific code, for example, if you have some of the classes generated automatically based on some meta-configuration, you will have to teach your generator to work with the namespace and make changes to the meta-configuration itself.
Conclusion
Switching to the namespace of an existing project can be both simple and complex, and much depends on what constructions for calls were used in it, how much your code is covered with tests, and how difficult it will be for you to change the “serving” code. Taking into account all these factors, you can assess the complexity and perhaps even give up the desire to use the namespace due to the high cost of the transition, or the high performance requirements of the functional.
I would also like to note that if your code is not intended for a wide range of uses, and your desire to input a namespace is justified only by aesthetic considerations of naming classes between projects, then it is worth considering the possibility of a gradual partial use of the namespace, for example, when entering a new code, you can start using namespace in this new code.