Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130044
Subject: Re: [PHP-DEV] [Vote] Add form feed as a whitespace character in trim,
 ltrim and rtrim
To: internals@lists.php.net
References: <4deea2df.a2a0.19be6247b75.Coremail.lamentxu@163.com>
 <20260130003750.5CA2A1A00BD@lists.php.net>
 <886205c77a8fdf08f4ddfb28b7605e51@bastelstu.be>
 <20260204011605.D6E871A00BD@lists.php.net>
 <9310fbfc-a7bc-44df-beac-5a46d6b14f61@app.fastmail.com>
 <CAMzRQTcPCx+DZQAZ6Tjahzb0USGtqAS6=dNKjpu+9Ntx-AupDA@mail.gmail.com>
 <8ec76a6c-3dba-4184-955c-cc8ee679a318@app.fastmail.com>
Message-ID: <69868019.40100@adviesenzo.nl>
Date: Sat, 7 Feb 2026 00:58:17 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
Precedence: list
MIME-Version: 1.0
In-Reply-To: <8ec76a6c-3dba-4184-955c-cc8ee679a318@app.fastmail.com>
Content-Type: multipart/alternative;
 boundary="------------090605040505020400090503"
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

This is a multi-part message in MIME format.
--------------090605040505020400090503
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 5-2-2026 17:00, Larry Garfield wrote:
> On Wed, Feb 4, 2026, at 11:09 AM, Volker Dusch wrote:
>> On Wed, Feb 4, 2026 at 3:41 PM Larry Garfield <larry@garfieldtech.com> wrote:
>>> Where as I would, because we catch flack every version for how many "small" BC breaks we have.  It hinders people's ability to upgrade and generates bad PR for PHP routinely.
>>>
>>> Majors exist for a reason.
>>>
>> That claim is completely unsubstantiated, doesn't reflect my
>> experienced and researched reality, and feels quite off-topic, given
>> PHP very much allows for this.
> Ask Juliette or MWOP how much the "minor" BC breaks cause them issues.
My ears were burning. And yes, "minor" BC breaks can definitely be 
hugely problematic, however, the "BC-break" proposed in this RFC - to me 
- is not one in that category. Feels more like a bug-fix.

--------------090605040505020400090503
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 5-2-2026 17:00, Larry Garfield
      wrote:<br>
    </div>
    <blockquote
      cite="mid:8ec76a6c-3dba-4184-955c-cc8ee679a318@app.fastmail.com"
      type="cite">
      <pre wrap="">On Wed, Feb 4, 2026, at 11:09 AM, Volker Dusch wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">On Wed, Feb 4, 2026 at 3:41 PM Larry Garfield <a class="moz-txt-link-rfc2396E" href="mailto:larry@garfieldtech.com">&lt;larry@garfieldtech.com&gt;</a> wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">
Where as I would, because we catch flack every version for how many "small" BC breaks we have.  It hinders people's ability to upgrade and generates bad PR for PHP routinely.

Majors exist for a reason.

</pre>
        </blockquote>
        <pre wrap="">
That claim is completely unsubstantiated, doesn't reflect my
experienced and researched reality, and feels quite off-topic, given
PHP very much allows for this.
</pre>
      </blockquote>
      <pre wrap="">
Ask Juliette or MWOP how much the "minor" BC breaks cause them issues.
</pre>
    </blockquote>
    My ears were burning. And yes, "minor" BC breaks can definitely be
    hugely problematic, however, the "BC-break" proposed in this RFC -
    to me - is not one in that category. Feels more like a bug-fix.<br>
  </body>
</html>

--------------090605040505020400090503--