Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119394
MIME-Version: 1.0
References: <CAFPFaMLtOAkRzTsqfdhvkZZ17JpUBg_WSQBpgVU6+xg-mLt2zA@mail.gmail.com>
 <5FC8DBAF-8D78-4E94-A3B0-3BDED3A3E53C@craigfrancis.co.uk> <789af205-4582-66a9-694a-10e18b8b9f56@demon-angel.eu>
 <CAFPFaMLAnCqhPFZHQXnABbw=aXXj53DwtaDOf=+zQ4jN1Z+OmA@mail.gmail.com>
 <9d225219-4e31-b362-52a9-9a298a0a55ef@telia.com> <CAFPFaM+X=H_qsVC2Nr-Qte52D0BQYxoJTxHCeh0qZNaH-ofoZg@mail.gmail.com>
 <768de46c-9ff2-eee2-24ab-e78e27ad167c@demon-angel.eu> <CAFPFaMJ362LKMcGK1=zkiUeA7pdsY=XYgtg49EfuQ32yP9LVUQ@mail.gmail.com>
 <828f1ec6-e8ff-01b2-dc0e-a6cf1dd16eb2@demon-angel.eu>
In-Reply-To: <828f1ec6-e8ff-01b2-dc0e-a6cf1dd16eb2@demon-angel.eu>
Date: Mon, 23 Jan 2023 13:06:07 +0000
Message-ID: <CAFPFaM+1G7QV7m=pjXwY9iZ98L6ncnBsupqCYd9+qcXCWcS8sA@mail.gmail.com>
To: Mark Baker <mark@demon-angel.eu>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000009b3e6905f2ee10e7"
Subject: Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
From: george.banyard@gmail.com ("G. P. B.")

--0000000000009b3e6905f2ee10e7
Content-Type: text/plain; charset="UTF-8"

On Fri, 20 Jan 2023 at 18:28, Mark Baker <mark@demon-angel.eu> wrote:

> The documentation page consistently uses the word Increment and
> Decrement, not Add 1 and Subtract 1.
>
> Developers who read the documentation should be aware of the Perl
> convention when dealing with alphabetic strings, and should expect that
> behaviour. Alphanumeric strings are certainly more problematic, less
> well documented, and less well understood, and I'll agree that they're
> inconsistent in their behaviour.
>

The PHP documentation has never been the source of truth about the PHP
implementation,
if it was dynamics properties should have been removed without any notice
as until them being deprecated there was no documentation.
So arguing *something* should behave a certain way because the docs are
written in a certain way holds no value to me.
The state of the PHP docs could certainly be improved, as it is blatantly
lying at various core sections.

However, the whole point of this RFC is to *remove* cognitive burden for
developers, so they don't even need to be aware of this "feature" and not
get surprised when it kicks in.
Moreover, by your logic, you wouldn't care if we removed support for
alphanumeric strings and only let the PERL increment kick in for purely
alphabetical.
While convenient for you, someone might actually use this feature on
alphanumeric strings, and we're back to "why is my use case being removed
while that other just as weird one remains".

I even went initially for such a proposal (see previous revision [1]),
however, I realized this provides minimal benefit as it doesn't reduce at
all the cognitive burden or the overall design specification of the
language.



> Deprecating the Increment operator for strings will create extra work
> for me, will affect many of the users of my library, and I'm certain it
> will also have a performance impact on the library (replacing that
> operation with a more expensive function call for alpha increments, but
> still having the operation for numeric increments). So yes, I am willing
> to die on this hill because that deprecation will have a very direct and
> adverse affect on my work.
>

If the issue is about performance, it is possible to enhance the optimizer
to inline those two functions (something the optimizer already attempts to
do for userland functions [2]).
The other aspect goes back to the typical conundrum: Do we think PHP is in
decline?
 - If yes, then not doing breaking changes and catering to legacy projects
is definitely the course of action to take.
 - If no, improving PHP for the next generation of developers and software,
so that it is easier to learn and reason about, should be the course of
action to take.

As I personally think we are in the second situation, that's why I'm
tackling this subject in this manner.
It's the same belief that made us deprecate dynamic properties, convert
warnings to Errors, etc.

Now, if we are in the former case, then you are totally justified, and I
probably should find another job as I see no point in not improving the
overall language semantics.

George P. Banyard

[1] https://wiki.php.net/rfc/saner-inc-dec-operators?rev=1669977388
[2] See zend_try_inline_call() function

--0000000000009b3e6905f2ee10e7--