The PHP Foundation
The PHP Foundation
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.
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.
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.
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.
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.
$_SERVER['REQUEST_TIME_FLOAT'] 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.
mail() throws TypeError after iterating over $additional_headers array by reference in GH-10991 by Niels DosscheReflectionObject::getProperties in GH-10984 by Niels DosscheXFAIL from test cases for mb_strcut when used with JIS or ISO-2022-JP encoding in c211e67b4e by Alex DowadXLEAK support in GH-10996 by Ilija Tovilo πadd_function_array() assertion when op2 contains op1 in GH-10975 by Ilija Tovilo πzend_alloc XLEAK support in GH-10999 by Ilija Tovilo πdom_zvals_to_fragment() in GH-10981 by Niels Dosschezend_constant struct in GH-10954 by MΓ‘tΓ© Kocsis πext/phar in GH-11009 by Niels DosscheZEND_CALL_FRAME_SLOT macro in GH-10988 by Tony Suzend_assign_to_typed_ref in b39107c774 by Ilija Tovilo πzend_std_write_property in 24acb4f134 by Dmitry StogovGC_DTOR/GC_DTOR_NO_REF macros in fdbea4f39e by Ilija Tovilo πzend_assign_to_typed_ref/prop in e1c6fb76c0 by Dmitry StogovUPGRADING.INTERNALS in 3528ca8930 by Ilija Tovilo πGC_DTOR and GC_DTOR_NO_REF in c796ce5713 by Dmitry Stogovzend_call_known_instance_method() instead of building FCI/FCC in serializer subroutine in GH-9955 by Gina Peter Banyard πzend_string_concat helper instead of strpprintf in 8e51cfe0ae by Gina Peter Banyard πchar* + size_t parameters to zend_string* in phar_find_in_include_path() in 7d93ef067f by Gina Peter Banyard πZEND_ADD_ARRAY_UNPACK_SPEC_HANDLER in GH-11021 by Niels DosscheXFAIL 'Various bugs exist'. They did, but they were in the tests in e67bb14ab4 by Derick Rethans πsapi/apache2handler/sapi_apache2.c in GH-10863 by Niels Dosschezend_string for DBA path in GH-10698 by Gina Peter Banyard πext/sockets adding FreeBSD's SO_REUSEPORT_LB constant in 6c532df705 by David CARLIERzend_string_starts_with_* APIs in GH-11032 by Gina Peter Banyard πext/phar: Prevent unnecessary known string length computation in GH-11033 by Gina Peter Banyard πext/phar: Remove duplicate cleaning-up code in 4082d425a9 by Gina Peter Banyard πUPGRADING in d64c7184d4 by Alex DowadNEWS on mb_detect_encoding; also include in UPGRADING in aa51871adc by Alex Dowadmb_encode_mimeheader in UPGRADING in a62d192ede by Alex DowadUPGRADING on mb_check_encoding changes in 7cef7cb0ee by Alex DowadFETCH_OBJ_W and FETCH_STATIC_PROP_W to return INDIRECT/UNDEF zval for uninitialized typed properties in GH-11048 by Dmitry Stogovext/curl: Protocol should be a case insensitive check in GH-11052 by Gina Peter Banyard πINI_SCANNER_TYPED in GH-11014 by Ilija Tovilo πext/phar: Fix recently introduced potential NULL dereferencement segfaults in GH-11065 by Gina Peter Banyard πHT_HASH_RESET in GH-11059 by Niels Dosschemb_parse_str, mb_http_input, and mb_convert_variables use fast text conversion code for automatic encoding detection in 6df7557e43 by Alex Dowadbug60120.phpt in GH-11064 by Ilija Tovilo πxxhash.h: Fix GCC 12 -Og in GH-11062 by Mingli Yuzval_undefined_cv in GH-11083 by Niels Dosschezend_test_crash funtion to segfault PHP process in GH-11082 by Jakub Zelenka πzend_test_crash message initialization in 84be9042f9 by Jakub Zelenka πext/openssl: pass ini options to extra processes in tests in 5a4083181b by Jakub Holubanskyparse_ini_string() in GH-11092 by Ilija Tovilo πCallbackFilterIterator::accept() in 5855bdcd6c by Ilija Tovilo π-Wenum-int-mismatch warnings on gcc 13 in GH-11103 by Ilija Tovilo πCG(memoize_mode) state after bailout in ??= in GH-11109 by Ilija Tovilo πext/intl: deprecate U_MULTIPLE_DECIMAL_SEPERATORS constant in 976d7ed4c6 by David CARLIERrefcount is 1 in GH-11060 by Niels Dosscheerror_log to an empty value if the test relies on that feature in GH-10772 by Niels Dossche__clone() method directly in 04a5f2b11f by MΓ‘tΓ© Kocsis πext/sockets: addig Linux's IP_BIND_ADDRESS_NO_PORT in 7b4b40f06f by David Carlierpg_lo_export() in GH-11132 by MΓ‘tΓ© Kocsis πSTREAM_DISABLE_OPEN_BASEDIR src flag to php_stream_stat_path_ex in GH-11156 by Ilija Tovilo πmbfilter_sjis.c in b915a1d8d7 by Niels DosscheAt 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.