Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119334
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>
In-Reply-To: <9d225219-4e31-b362-52a9-9a298a0a55ef@telia.com>
Date: Wed, 18 Jan 2023 20:25:04 +0000
Message-ID: <CAFPFaM+X=H_qsVC2Nr-Qte52D0BQYxoJTxHCeh0qZNaH-ofoZg@mail.gmail.com>
To: php internals <internals@lists.php.net>
Cc: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= <bjorn.x.larsson@telia.com>, 
	Derick Rethans <derick@php.net>, Levi Morrison <levi.morrison@datadoghq.com>, autaut03@gmail.com
Content-Type: multipart/alternative; boundary="0000000000003feb0305f28f9dcb"
Subject: Re: [PHP-DEV] [RFC] Path to Saner Increment/Decrement operators
From: george.banyard@gmail.com ("G. P. B.")

--0000000000003feb0305f28f9dcb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, 18 Jan 2023 at 14:35, Bj=C3=B6rn Larsson <bjorn.x.larsson@telia.com=
>
wrote:

> 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 h=
as
> been RFC's that required multiple tries to fly.
>

Possibly, and I could wait for the result of such an RFC, but I do not
intend on pushing this forward.

On Wed, 18 Jan 2023 at 15:32, Derick Rethans <derick@php.net> wrote:

> On Tue, 17 Jan 2023, G. P. B. wrote:
>
> > I would like to start the discussion on the Path to Saner
> > Increment/Decrement operators RFC:
> > https://wiki.php.net/rfc/saner-inc-dec-operators
> >
> > The goal of this RFC is to reduce language complexity by making $v++
> > behave like $v +=3D 1 and $v-- behave like $v -=3D 1;
>
> If that is the goal, then I would agree with this RFC.
>
> However, changing the PERL string increment feature does not IMO fit
> into that goal, and it also a useful *feature*. On that base I would
> vote against this. And I suspect many others would as well.
>

I do not understand how this does *not* fit into that goal.
$s =3D "a10";
$s +=3D 1;
var_dump($s);
Results in a TypeError whereas
$s =3D "a10";
$s++;
var_dump($s);
Results in string(3) "a11"

Therefore, $s++ does not behave like $s +=3D 1; and thus in scope.

Is there a way to avoid this single useful feature from being
> deprecated, while to good parts of this RFC stay?
>

Yes, but at that point, I don't see why we should unify the behaviour if it
is going to remain inconsistent. Might as well make incrementing on bool,
and decrementing null a TypeError in PHP 9 to make it stricter.


> I am also unsure as how much actual breakage this would cause, and
> before this gets up to a vote, I would like to see how bad (or not) this
> would affect already existing code bases.
>

Fair point, I can try and run Nikita's script on the top composer packages,
but that won't show the state of private codebases.

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

--0000000000003feb0305f28f9dcb--