PHP Core Roundup #12

The PHP Foundation is a collective of PHP contributors, veterans, and companies that collaborate to ensure the long-term sustainability of the PHP programming language. Started over a year ago, the PHP Core Roundup series deliver a summary of the latest developments, discussions, and news about PHP Core made by both PHP Foundation members and other contributors. This post is the twelfth in the PHP Core Roundup series.

The PHP Foundation currently supports six part-time PHP contributors who work on maintenance and new features for PHP. Maintenance is not limited to fixing bugs, but also includes work to reduce technical debt, making life easier for everyone working on PHP. The contributors funded by the PHP Foundation collaborate with other contributors on code, documentation, and discussions.

We publish the posts on our website, and you can subscribe to a newsletter; You don’t necessarily have to be a PHP Foundation backer to follow PHP Core Roundup.

PHP 8.3 Release Managers Elected

Release managers for PHP 8.3 were elected from a vote that ended on April 16.

Pierrick Charron, one of the PHP 8.2 release managers stepped in to be the veteran release manager, and Jakub Zelenka 💜 and Calvin Buckley were elected as the "rookie" release managers. Jakub Zelenka is one of the PHP Foundation members.

Release managers are responsible for triaging bugs and security vulnerabilities, signing and releasing tagged PHP releases, communication, and other management tasks until the PHP version reaches its End-Of-Life.

Discussions on PHP Governance and Communication

During the last month, there were several mailing list discussions about PHP governance and communication. These lengthy discussions lead to an RFC (currently in vote) to form a "PHP Technical Committee", and a discussion on moving PHP Internals mailing list to GitHub issues and discussions.

While the PHP Foundation seeks the long-term sustainability of the PHP project by funding full-time and part-time PHP contributors and acting as a collective for other PHP initiatives, the RFC for the technical committee and the discussion on moving the PHP Internals mailing list to GitHub remained the discussion of all PHP contributors.

The Technical Committee RFC intends to form an elected group of PHP contributors who will focus on PHP internal changes. User-facing changes such as PHP APIs would still go through the current RFC voting process. RFC discussion and an in-vote discussion provide more context. Jakub also emailed the PHP Internals with Current RFC process and project decisions to provide more information.

Moving PHP internals to GitHub is also a lengthy discussion on highlighting some of the flaws of the current mailing list approach to discussions, and proposing to use GitHub Discussions and issues for the communication amongst PHP contributors and users.

Recent RFCs and Mailing List Discussions

Changes and improvements to PHP are discussed, reported, and voted on by the PHP Foundation Team, the PHP development team, and contributors. Bug reports are made to the PHP issue tracker, changes are discussed in mailing lists, minor code changes are proposed as pull requests, and major changes are discussed in detail and voted on as PHP RFCs. Documentation and the php.net website changes are also discussed and improved at their relevant Git repositories on GitHub.

Hundreds of awesome PHP contributors put their efforts into improvements to the PHP code base, documentation, and the php.net website. Here is a summary of some changes made by the people behind PHP. Things marked with 💜 are done by the PHP Foundation team.

RFC Updates

Following are the RFCs and major pull-requests discussed, voted on, and implemented since our last update.

• RFC In Vote: PHP Technical Committee by Jakub Zelenka 💜 and Larry Garfield

  As mentioned above, proposes to establish a technical committee to take decisions on PHP internal API changes and other technical aspects.

• RFC Under Discussion: Deprecate functions with overloaded signatures by Máté Kocsis 💜

  PHP does not support method overloading similar to Swift or Java. However, there are some internal PHP functions and methods that accept multiple function/method signatures that behave differently. For example, the session_set_save_handler function accepts several callable parameters or a single SessionHandlerInterface implementation.

  While there are historical reasons for those internal functions to provide multiple signatures, part of of the long-term language streamlining goals of PHP is to get rid of these inconsistencies. This RFC proposes to deprecate several overloaded functions and methods. For each of the deprecated signatures, the RFC proposes a new function or a method, or to eventually remove the deprecated signature in the next major PHP version (PHP 9.0 as for now).

• RFC Under Discussion: Clone with by Máté Kocsis 💜

  Proposes a new "clone with" construct to PHP to address to too strict nature of readonly properties. As of PHP 8.2, readonly properties can be too strict and do not provide the means to create immutable objects that remain immutable at an object level, because cloned objects remain read-only too.

  class Response implements ResponseInterface {
     public readonly int $statusCode;
     public readonly string $reasonPhrase;
     // ...
     public function withStatus($code, $reasonPhrase = ''): Response
     {
         return clone $this with {
             statusCode: $code,
             reasonPhrase: $reasonPhrase
         };
     }
     // ...
  }
  
  $response = new Response(200);
  $response->withStatus(201)->withStatus(202);
  

• RFC Under Discussion: New core autoloading mechanism with support for function autoloading by Gina Peter Banyard 💜 and Dan Ackroyd

  PHP has had support for class autoloading since PHP 5 and it is an extremely useful feature that is relied on to only load classes that are being used within the current request. However, the current autoloading mechanism does not support autoloading functions.

  The need for such a feature seems very clear as users will create “helper” classes with static methods to take advantage of autoloading via the class autoloading mechanism.

  The proposal consists of adding a better designed class autoloading mechanism and a new function autoloading mechanism, and aliasing the existing autoload functions to the new versions. The proposal does not include a default implementation for either the class or the function autoloading mechanism.

  Eight newly proposed autoload_(register|unregister|call|list)_(class|function) functions will be used to register, unregister, call, and list autoloaders for both classes and functions. Existing spl_* functions are proposed to be aliased to the new functions.

  Further, function_exists will get a new parameter $autoload similar to class_exists() to trigger the autoloader if necessary.

• RFC Accepted : Arbitrary static variable initializers by Ilija Tovilo 💜

  PHP does not allow using arbitrary expressions in static variable initializers because the values are initialized at the compile time. This also lead to some unexpected behaviors when the same variable is initialized in more than once within the same scope.

  This RFC proposes to remove the current limitation of not allowing expressions in static variable initializers. It also forbids redeclaring static variables altogether.

  function foo() {
   static $i = getValue();
  }
  

  This RFC was accepted by the vote, and will be implemented in PHP 8.3.

• RFC Implemented: Make unserialize() emit a warning for trailing bytes by Tim Düsterhus

  This RFC proposes that unserialize() shall emit a new E_WARNING whenever the input string contains additional bytes once the unserialization parser terminates after successfully parsing a value. In other words: A warning shall be emitted if bytes can be removed from the end of the input string without changing the return value of unserialize().

  The RFC vote unanimously accepted this change, and it is already implemented for PHP 8.3.

Notable Mailing List Discussions

• Final anonymous classes
• [Discussion] Callable types via Interfaces
• Expansion of PHP Symbols?
• Future stability of PHP?
• Moving PHP internals to GitHub
• Brainstorming idea: inline syntax for lexical (captured) variables
• Possible RFC: $_SERVER['REQUEST_TIME_FLOAT']
• [RFC] PHP Technical Committee
• Array spread append
• PHP Modules
• Property Hooks Discussion

Merged PRs and Commits

Following are some changes that did not go through an RFC process because they are either planned, bug fixes, or progressive enhancements. There are automated unit and integration tests for each of these changes, the PHP core developers review all pull requests.

Full list of commits since PHP Core Roundup #11

Support PHP Foundation

At PHP Foundation, we support, promote, and advance the PHP language. We financially support six part-time PHP core developers to contribute to the PHP project. You can help support PHP Foundation at OpenCollective.

A big thanks to all our sponsors — PHP Foundation is all of us!

Follow us on Twitter @ThePHPF to get the latest updates from the Foundation.

💜️ 🐘

PHP Roundup is prepared by Ayesh Karunaratne from PHP.Watch, a source for PHP News, Articles, Upcoming Changes, and more.