Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119306
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>
In-Reply-To: <789af205-4582-66a9-694a-10e18b8b9f56@demon-angel.eu>
Date: Wed, 18 Jan 2023 12:22:50 +0000
Message-ID: <CAFPFaMLAnCqhPFZHQXnABbw=aXXj53DwtaDOf=+zQ4jN1Z+OmA@mail.gmail.com>
To: mark@demon-angel.eu
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000009a8ae405f288e0d0"
Subject: Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
From: george.banyard@gmail.com ("G. P. B.")

--0000000000009a8ae405f288e0d0
Content-Type: text/plain; charset="UTF-8"

On Tue, 17 Jan 2023 at 18:28, Mark Baker <mark@demon-angel.eu> wrote:

> On 17/01/2023 17:28, Craig Francis wrote:
> > I've seen this used a few times, e.g. starting with a numerical value
> (Passport number, NHS number, Social Security Number, Date of Birth
> 20230117), and the developer simply appends an incrementing letter on the
> end to get a unique reference; e.g. a person having multiple assessments...
> especially if it's more than 26 (A-Z), and you need to move to multiple
> letters, which `chr(90 + 1)` cannot help you with.
>
> Being able to increment alpha strings is incredibly useful when working
> with Excel spreadsheets (as I do on a daily basis), because the column
> Ids match this pattern; and I would hate to see this deprecated. Having
> to replicate that logic for traversing column Ids in userland code would
> be inconvenient (to say the least), would affect many of the users of my
> libraries, and would have a performance impact on my libraries. If
> anything, I'd rather like to see the decrement operator work with alpha
> strings as well for more consistency.
>
> I don't have the karma for a vote; but if I did then it would be a "No"
> for this alone, because I can see the problems that it will cause me and
> the users of my libraries.
>
>
> > That said, I appreciate that incrementing some strings can be a bit
> unusual (e.g. "A9" to "B0", vs "A 9" to "A 0").
>
> Agreed. While incrementing works in a very logical manner with mixed
> alphanumeric strings, it's not well documented behaviour, and most
> developers take a long time before they understand what it's actually
> doing. While there might be use cases for incrementing alphanumerics, I
> suspect that it would be better implemented in the business logic of an
> application, because the component parts of that string are likely to
> have business meaning; and also to provide better code readability.
>

I appreciate being shown concrete cases about the useful ness of this
operation.
The reason I didn't go with adding support for decrementing alphanumeric
strings is that it was unanimously rejected.
However, if Rowan's suggestion of adding
string_increment()/string_decrement() with more rigorous behaviour (that we
can flesh out together) would be part of this proposal, would you be more
inclined to accept deprecating ++ from performing this feature?

I truly believe having $v++ behave like $v += 1 and $v-- behave like $v -=
1; is something to strive for *because* it allows us to remove one
dedicated type juggling context people need to be aware of and simplifies
the overall semantics of the language.
Keeping support for string increments means that one cannot interchange $v++
and $v += 1 and that one needs to be aware about using it when a value
might hold a string.
As such, if it needs to remain its own type juggling context, the question
is why not make it stricter by having it warn and then throw a TypeError on
bool, reopening the can of worms that is the null handling between both
operators and what to do with the empty string case.
These questions are already answered by making those operators behave just
like addition/subtraction.

My order of preference for the semantics are as follows:
1. The behaviour described in the RFC (with or without function for string
in/decrement)
2. (with a massive gap, but I could live with it) adding support for string
decrements and tiding up the behaviour of the alphanumeric string to make
it stricter and less error-prone.
3. The current asymmetry (again with a massive gap between this and option
2)

But because option 2 seems out of the question due to the unanimous
rejection of https://wiki.php.net/rfc/alpanumeric_decrement, the only
viable options to me seem like 1 and 3.
As I hate option 3 I am pushing for option 1 as I think it has various
benefits.

Moreover, I do not want to split this into its own proposal (deprecating
string increments/figuring out what to do with them) as I feel it will make
any attempt to improve the situation harder.

Best regards,

George P. Banyard

--0000000000009a8ae405f288e0d0--