Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119339
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1187-g678636ba0d-fm-20230113.001-g678636ba
Mime-Version: 1.0
Message-ID: <9283e65e-f25b-4de9-8fbc-f987c4ff7349@app.fastmail.com>
In-Reply-To: 
 <CAFPFaM+X=H_qsVC2Nr-Qte52D0BQYxoJTxHCeh0qZNaH-ofoZg@mail.gmail.com>
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>
Date: Wed, 18 Jan 2023 16:55:39 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
From: larry@garfieldtech.com ("Larry Garfield")

On Wed, Jan 18, 2023, at 2:25 PM, G. P. B. wrote:

> On Wed, 18 Jan 2023 at 16:03, Levi Morrison <levi.morrison@datadoghq.com>
> wrote:
>
>> It seems to me that if you truly want to clean up this specific part
>> of the language, you are going to have to play the long game:
>>  1. New functions are added for the perl behavior of string increment
>> and decrement. No warnings are given in code, but call-outs are made
>> in upgrading and other documentation about this behavior changing.
>> Note that in the past I would have used an E_STRICT for this, but
>> people seem opposed to adding new E_STRICT warnings.
>>  2. In the next minor version, we add a warning about the behavior
>> when string increment/decrement is used.
>>  3. In the next major version, we finally clean up the behavior.
>>
>> But this gets muddy if we do PHP 8.3 for step 1, and then we decide to
>> go for PHP 9.0 instead of 8.4, and it messes with the "ideal" cycle.
>>
>> Note that I support this sort of plan, and would support it for
>> cleaning up many other parts of PHP as well. It's just unfortunate it
>> takes so long, but that's how it goes sometimes :/
>
>
> I don't think we need such a long timeline because the function is easily
> poly filled.
> Moreover, if people jump a version in an upgrade, they are still going to
> immediately receive a warning/deprecation.
> But if such a timeline is preferred, I do not mind changing it.
>
> On Wed, 18 Jan 2023 at 18:33, Alex Wells <autaut03@gmail.com> wrote:
>
>> Classes and methods is the expected way of implementing standard library in
>> an OO language. New APIs (such as the new Random api) use OO instead of
>> functions and it makes more sense to use OO in this case too: there's
>> likely a place for other methods too, like toBase(int $otherBase) etc. It
>> would also be possible to use overloaded operators if needed.
>
>
> Until we have strings that can invoke methods, I don't see the point of
> having an OO API.
> PHP is a multi paradigm language, and creating a class with two methods
> seems very useless to me.
> OOP is favoured in PHP because using functions is just an overall terrible
> experience that needs improvements, but using functional patterns is
> totally doable (and can produce elegant code) in PHP.
>
> George P. Banyard

I agree that adding a str_increment() function and then (later) deprecating and removing the ++ functionality is the way to go.  I defer to George if it makes sense to fix the other parts of ++ now and wait for 9 for string-incrementing, or just wait and get rid of them all at once.

While str_increment() is less ergonomic than ++, I think the improved type consistency is worth it.  And it's trivial to wrap up into a generator if one wants something shorter:

function cols(string $s): \Generator
{
    while (true) {
        $s = str_increment($s);
        yield $s;
    }
}

$it = cols('A');
$it->next(); // gives B

And that can be made parallel with something on the number side if you really want.

--Larry Garfield