PHP Core Roundup #13
Published on June 8, 2023 by Roman Pronskiy
On this day, June 8th, PHP turns 28 years old!
Here's to many more years of empowering developers and pushing the boundaries of web technology. Happy Birthday, PHP! 🎉🥳🎂
The PHP Core team has been as productive as ever this past month, bringing forth a robust collection of updates that promise to shape the future of PHP. From RFCs that are sure to stir up lively debate, to ones that bring small, yet impactful changes, it has been a month filled with interesting developments. Here's what you need to know.
Here's to many more years of empowering developers and pushing the boundaries of web technology. Happy Birthday, PHP! 🎉🥳🎂
The PHP Core team has been as productive as ever this past month, bringing forth a robust collection of updates that promise to shape the future of PHP. From RFCs that are sure to stir up lively debate, to ones that bring small, yet impactful changes, it has been a month filled with interesting developments. Here's what you need to know.
Started over a year ago, the PHP Core Roundup series offers a summary of the latest developments, discussions, and news about PHP Core, contributed by both PHP Foundation members and other participants. This post is the thirteenth in the PHP Core Roundup series.
Releases
The PHP development team released two new versions in May 2023:
This release includes several bug fixes and improvements, notably in areas such as Core, Date, DOM, Exif, Intl, PCRE, Reflection, SPL, Standard, and Streams.
This release includes bug fixes across various components such as Core, DOM, Exif, Intl, PCRE, and Standard.
Recent RFCs and Mailing List Discussions
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.
In Voting: Define proper semantics for range() function by George Peter Banyard 💜
This RFC proposes to adjust the semantics of the range() function in PHP to throw exceptions or at least warn when passing unusable arguments to range().
The range() function in PHP generates an array of values going from a start value to an end value. However, the current behavior of the function is complex and can lead to unexpected results. For example, if one of the boundary inputs is a string digit (e.g. "1"), both inputs will be interpreted as numbers. This RFC aims to address these issues and make the behavior of the range() function more predictable and consistent.
In Voting: mb_str_pad() by Niels Dossche
This RFC proposes the addition of a multibyte string pad function to the mbstring extension. This function would work similarly to the existing str_pad() function, but with support for multibyte strings. This is a welcome addition for developers working with multibyte strings, as it will make it easier to manipulate and format these strings in PHP.
Under Discussion: Nameof by Robert Landers
This RFC proposes to add a global nameof() function, which would return the name of a variable, class, function, or method as a string. This could be useful in a variety of scenarios, such as debugging, logging, or creating more informative error messages.
Under Discussion: Marking Overridden Methods by Tim Düsterhus
This RFC proposes a way to explicitly mark methods that are intended to override methods from a parent class with a new #[\Override] attribute. If this attribute is added to a method, the engine shall validate that a method with the same name exists in a parent class or any of the implemented interfaces. If no such method exists a compile time error shall be emitted.
The similar concepts exist in Java, TypeScript, C++, C#, Swift, Kotlin, and other languages.
Under Discussion: Deprecate Functions with Overloaded Signatures by Máté Kocsis 💜
This RFC proposes to deprecate a number of functions that have overloaded signatures, meaning they behave differently based on the number or type of arguments passed to them. The goal is to make PHP's function signatures more consistent and predictable.
Under Discussion: Deprecations for PHP 8.3 by George Peter Banyard 💜, Christoph M. Becker, Máté Kocsis 💜, Tim Düsterhus, Go Kudo, Andreas Heigl
The aim is to clean up some of the older, less consistent parts of PHP to make the language more reliable and predictable. The following list provides a short overview of the functionality targeted for deprecation:
- Passing negative $widths to mb_strimwidth()
- The NumberFormatter::TYPE_CURRENCY constant
- Unnecessary crypt() related constants
- MT_RAND_PHP
- Global Mersenne Twister
Declined: PHP Technical Committee by Jakub Zelenka 💜 and Larry Garfield
This RFC proposed the creation of a PHP Technical Committee (TC) that would make decisions about technical aspects of the PHP language and its reference implementation. The TC would have been responsible for resolving technical conflicts between core developers. Despite the potential benefits, the community decided not to move forward with this proposal.
Notable Mailing List Discussions
Callable types via Interfaces
The proposal suggests that callable types should be allowed to be represented as interfaces, which would allow for more precise type hinting and better static analysis. The sentiment in the thread is generally positive, with many participants expressing support for the idea. However, some concerns were raised about potential complexity and the need for careful implementation to avoid breaking existing code.
Interface Properties
The discussion starter suggests making it possible to define properties in interfaces and argues that this feature would align well with the deprecation of dynamic properties and could replace the current practice of specifying these properties in doc blocks.
Larry Garfield pointed out that interface properties are already included in the Property Hooks RFC, which is expected to go to a vote soon.
David Gebler expressed his disagreement with the proposal, stating that interfaces in most languages don't support defining properties because they are generally seen as an implementation detail rather than a promise about supported behavior. He also mentioned that interfaces are essentially an alternative to multiple inheritance, and mandating fields as well as method signatures brings them very close to abstract classes. He also expressed concerns about multiple interfaces defining the same property, which could lead to conceptual confusion.
Some participants expressed support, noting that it could improve code clarity and reduce the need for doc blocks.
Merged PRs and Commits
This month, the PHP core team has been hard at work improving the PHP language. See a list of the commits made by the team and grouped by author here.
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 or via GitHub Sponsors.
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 (except for this particular one) prepared by Ayesh Karunaratne from PHP.Watch, a source for PHP News, Articles, Upcoming Changes, and more.
🎉 1