Re: [Vote] Add form feed as a whitespace character in trim, ltrim and rtrim
| From: | Gina P. Banyard | Date: | Thu, 05 Feb 2026 17:21:36 +0000 |
| Subject: | Re: [Vote] Add form feed as a whitespace character in trim, ltrim and rtrim | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-130019@lists.php.net to get a copy of this message | ||
On Thursday, 5 February 2026 at 16:04, Larry Garfield <larry@garfieldtech.com> wrote:
> Nikita's proposal for "Editions":
> https://externals.io/message/106453#106454
Nikita's edition proposal explicitly moved out of scope library changes, which ext/standard is.
[1]
> But when we can ensure that upgrades are smooth and uneventful, we should..
Every single minor release, we implement bug fixes that we deem too disruptive to do in a stable
branch.
Sometimes due to behavioural changes, which I will reiterate this very much feels like a bug fix to
me.
Moreover, in the current state of the project it is extremely unreasonable to demand that any minor
thing be pushed back who knows how many years.
We didn't even properly handle removing all deprecation in PHP 8.0 and so have been carrying
these deprecations for another 5 years.
You could not expect from the core team to spend a year + just converting resources to opaque
objects, that's why it was done in stages in multiple minor releases.
(and once again this wouldn't have been an issue if those extensions didn't live in the
php-src repo and weren't tied to PHP's release process.)
And we have lost *multiple* contributors to core because they were explicitly told the thing they
were working on they should have submitted 5-6 years earlier or should wait until PHP 9.
Forcing everything to wait until the next major is a sure fire way of demotivating new people from
working on the language.
Recently, discussion about fixing minor things in PHP seem to always get sidetracked by people who
are not actively involved in the maintenance of PHP questioning every single decision even if those
processes have been established for years.
Sometimes those are undocumented, but event after clarifying some, there is still constant
questioning.
This makes working on PHP a chore and wastes a lot of people's time (and money) re-iterating
existing practice, while holding the evolution of the language back.
Given how we discuss these things these days, I don't think I would have started to contribute
to PHP if I started getting involved in 2025.
Best regards,
Gina P. Banyard
[1] https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/0000-language-evolution.md#scope-and-eligible-changes