Tony Marston's Blog About software development, PHP and OOP

Is there a case for adding namespaces to PHP core?

Posted on 8th April 2023 by Tony Marston

There are two ways in which an idea can be implemented - intelligently or indiscrimiately. An idea is usually developed for a particular set of circumstances, so when those circumstances do not exist then implementing that idea could either be a complete waste of time, or a hindrance instead of a help. Instead of being a solution to a problem it could become a problem itself.

Namespaces were added to PHP in version 5.3 with the following explanation:

In the PHP world, namespaces are designed to solve two problems that authors of libraries and applications encounter when creating re-usable code elements such as classes or functions:
  1. Name collisions between code you create, and internal PHP classes/functions/constants or third-party classes/functions/constants.
  2. Ability to alias (or shorten) Extra_Long_Names designed to alleviate the first problem, improving readability of source code.

You should be able to see this feature was designed to be used by those whose code may be plugged into an unknown application containing unknown source code with an unknown naming convention, and this applies only to the authors of third-party libraries.

The use of namespaces is optional, but should you use them or not? As with a lot of questions the answer is "It depends". While namespaces are a solution to a particular problem, if you do not actually have that problem then implementing the solution may not be a good idea as it would violate the YAGNI principle. You should therefore ignore the use of namespaces unless the potential for name collisions actually exists. In any PHP application the names used can appear in one of the following levels:

  1. The PHP language itself, known as PHP core.
  2. In an optional extension, which is a pre-compiled object written in C and documeted in the PHP manual.
  3. Application code.
  4. Third-party libraries, such as those to be installed via composer.

Name collisions can only occur when code from two of these levels is mixed when names used in a lower level clash with names used in a higher level. Functions and classes inside PHP core (level 1) do not need to use namespaces this is at the top level and has nothing with which it can clash.

When writing a PHP extension (level 2) the practice has always been that each extension has its own unique mnemonic, as documented in the PHP manual, which is used as a prefix in all class and function names. Methods inside a class need no such prefix as it is only the class name which need be unique. No extension can be released if it has names which clash with either PHP core or another extension.

When writing application code (level 3) the developer should not use a name which is documented in the PHP manual, either within PHP core or an extension, as this would generate an error and the code would refuse to run. This is an error which the application developer should correct in his own code by using another name.

When writing a 3rd-party library (level 4) the library developer has no knowledge of any application in which it may be incorporated, so it is possible to use both class and function names which may already be used within that application. Collisions are avoided by using a namespace which usually incorporates a unique mnemonic similar to that used in extensions (level 2). In this way none of the code within any 3rd-party library can ever clash with any other code. Nowadays the standard practice is to install 3rd-party libraries via composer which forces the use of namespaces. When using an older library which is not installed via composer or which does not use namespaces then collisions may occur and will be cumbersome to resolve.

The only time that name collisions could legitimately occur is when adding third-party libraries (level 4) into application code (level 3), but as this is done nowadays via composer which requires the use of namespaces the potential for any collisions is avoided.

While some application developers think that using namespaces in their code is a good idea it actually is not. The potential for name collisions with third-party libraries which are installed via composer has already been negated, so the only possible collisions are with PHP core or an extension, in which case the developer should choose a different name. Namespaces in application code are therefore redundant. The could be used, but they would be solving a problem which does not exist.

Similarly the PHP core developers need not worry about name collisions as they only concern application and library developers. If a core developer uses a name that already exists in core then his code will fail to compile and he will have to choose a different name.

While some people say that now namespaces exist they should be used everywhere whether they are useful or not I believe that this would violate the YAGNI principle. When people look at my code and ask me why I don't use namespaces they do not seem to understand when I answer "Because I don't have the problem which they solve". They respond with "But you are not keeping up with changes to the language". They seem to think that just because a new feature has been added to the language then I should use it to make my code somehow "better" or "up-to-date".

Namespaces are only necessary in 3rd-party libraries, and as these are installed via composer which already requires the use of namespaces, the potential for name collisions no longer exists.

So, to the question "Is there a case for adding namespaces to PHP core?" my answer is "No, there is not".

To the question "Is there a case for adding namespaces to PHP extensions?" my answer is "No, there is not".

To the question "Is there a case for adding namespaces to application code?" my answer is "No, there is not".

To the question "Is there a case for adding namespaces to 3rd-party libraries?" my answer is "Yes, but these are (or should be) installed via composer which already requires the use of namespaces".