Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119308
Message-ID: <9d225219-4e31-b362-52a9-9a298a0a55ef@telia.com>
Date: Wed, 18 Jan 2023 15:35:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Content-Language: sv
To: "G. P. B." <george.banyard@gmail.com>, Mark Baker <mark@demon-angel.eu>
Cc: php internals <internals@lists.php.net>
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>
Reply-To: =?UTF-8?Q?Bj=c3=b6rn_Larsson?= <bjorn.x.larsson@telia.com>
In-Reply-To: <CAFPFaMLAnCqhPFZHQXnABbw=aXXj53DwtaDOf=+zQ4jN1Z+OmA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
From: internals@lists.php.net ("Björn Larsson via internals")

Den 2023-01-18 kl. 13:22, skrev G. P. B.:
> 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.

Since the alpanumeric_decrement RFC was rejected january 2014 9 years ago,
could it be an option to bring it up again in conjunctione with your RFC?

Maybe the added value of your RFC could swing the opinion. I mean there has
been RFC's that required multiple tries to fly.

Regards //Björn L