Contrib.social

Namespace all Drupal PHP code (esp. procedural)

Open on Drupal.org →
Created on 3 January 2012, over 13 years ago
Updated 26 June 2023, almost 2 years ago

All Drupal PHP code should be in it's own namespace.

By declaring the namespace at the top of each PHP file, it automatically prefixes functions and classes with 'Drupal\' . This means that the 'drupal_' prefix can be removed from function names and 'Drupal' removed from class names.

Advantages

  • It prevents namespacing collisions with functions and classes in other PHP software, e.g. #1370032: render() function defined by other PHP libraries → .
  • We don't have to prefix our functions to prevent the above problem from happening. Currently some functions are prefixed and some are not.

    Prefixes are used for our PHP Wrappers , but because this is not the only use of prefixes it is not a reliable way to determine if a function is a PHP wrapper or not.

    It is not the case that it can be determined if a function is defined by PHP or Drupal by looking at the name. Most Drupal functions are not prefixed.

    Removing the Drupal prefix from all functions that are not PHP wrappers removes ambiguity. It also makes the code much more readable. We do not need to continually declare that every function is part of Drupal when we are in our own codebase!

  • It paves the way for potentially putting each module in it's own namespace.

I have managed to put all of Drupal 8 into it's own namespace with 100% of tests passing.

How it works

A script does most of the heavy lifting. This is followed by a patch that tidies everything up and ensures that all tests pass.

Both are attached. There are also two binary files attached. These files are gzipped PHP files and so couldn't be included in the patch and must be placed in core/modules/simpletest/tests/upgrade .

The script:

  • puts 'namespace Drupal;' at the top of every file.
  • imports any global classes that the file needs with the 'use' command.
  • removes 'drupal_' from function names except all PHP wrappers and
    • drupal_static() / drupal_static_reset() - this would be shortened to just 'static' which is a reserved word. In a way it can be considered a PHP wrapper.
    • drupal_render() - there are currently two functions: drupal_render() and render(). I couldn't determine how best to rename these functions.
    • drupal_goto() is renamed to redirect() because 'goto' is a reserved word. This also brings the terminology into line with the form api.
  • removes Drupal components from class and interface names
  • fixes drupal_static_reset() calls. The identifier is typically a function name and so must be prefixed with 'Drupal\'

The patch fixes all the tests. This primarily consists of fixing dynamic function calling - Drupal invokes a lot of functions like this, e.g. module hooks. Anytime a function or class name is referred to in a string, it must be prefixed with 'Drupal\' .

The testbot will fail because Drush does not understand namespaces.

I would encourage you to browse the consolidated patch or apply the patch and browse your favourite file to see what the changes look like.

📌 Task
Status

Postponed: needs info

Version

9.5

Component
Base  →

Last updated about 5 hours ago

Created by

🇬🇧United Kingdom jbrown

Live updates comments and jobs are added and updated live.
  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment almost 2 years ago →
    🇺🇸United States smustgrave

    Wonder if the issue summary could be updated around D10.

  • Status changed to Closed: outdated 12 days ago
  • Comment 12 days ago →
    🇳🇿New Zealand quietone

    This was closed 12 years and re-opened for more work. However, that has not happened and 2 years ago it was asked if this issue is still needed. Since there has been no reply, I am closing this issue.

    If there is work to do here, then either re-open the issue and add a comment or open a new issue and reference this one.

  • Comment 12 days ago →
    🇩🇪Germany donquixote

    Now we have the path forward to drop a lot of procedural code (OOP hooks, OOP theme preprocess), there is no more need to move existing procedural code into namespaces.
    It would be a lot of disruption for no or very little benefit.

    So, I am ok to see this closed.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024