Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108801
MIME-Version: 1.0
References: <3f615d82-a84b-697b-5c02-8d915270f92c@gmail.com>
In-Reply-To: <3f615d82-a84b-697b-5c02-8d915270f92c@gmail.com>
Date: Mon, 2 Mar 2020 11:22:57 +0200
Message-ID: <CAAwdEzB6QjUnjWCh8-Tp9pr93gExgsHhw3s+N9xp+-QPuG7t7g@mail.gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000070f879059fdbbc29"
Subject: Re: [PHP-DEV] [RFC] Increment/Decrement Fixes
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--00000000000070f879059fdbbc29
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Rowan,

Thank you for the effort, very good unification of behavior across
increment and decrement operations.
I would say that all 3 points are most probably code issues and potential
bugs.
I agree with all of them.

For point 3, the new behavior is an error. The problem will be caught
earlier in any production code.

For point 1 and 2, both the old and new behavior is silent. Can we think of
a safer way to migrate?
I'm thinking about having a special notice that can be used before changing
the behavior and code running an old version could have some handler to
catch it and at least be aware of the change.

Have a mechanism like this ever been proposed on internals list?
The "special notice" I mentioned could be something like an information
debug behavior that can configuration for each debugging type statically in
ini settings, used before parsing and have no impact on production code
when disabled.
New debugging types can be added in patch versions for older PHP version
(now 7.2, 7.3 and 7.4), preparing for minor/major BC changes and removed
after migration (now 8.0).
When upgrading production applications, I always wished to have something
like this available for BC changes. We even consider recompiling PHP with
some changes here and there where it would have been harder to find the
issue statically but we didn't go through with it.
We can even do it back for BC changes 7.2->7.3 and 7.3->7.4.
Let me know if this would be a good idea and I can start a topic on this as
it has nothing to do with this RFC.

Regards,
Alex








On Sun, Mar 1, 2020 at 11:23 PM Rowan Tommins <rowan.collins@gmail.com>
wrote:

> Hi all,
>
> Following my thread a couple of weeks ago, I would like to put forward
> an RFC to fix some inconsistencies with the behaviour of the ++ and --
> operators:
>
> https://wiki.php.net/rfc/increment_decrement_fixes
>
> Note that this RFC focusses on three specific cases which I think could
> be considered bugs, but require breaking compatibility:
>
> 1) Bring the behaviour of decrementing null in line with subtracting 1
> (and with the equivalent increment operator)
> 2) Bring the behaviour of incrementing or decrementing true and false in
> line with adding or subtracting 1
> 3) Throw the same error when incrementing or decrementing an array as
> when adding or subtracting 1
>
> I believe the behaviour of strings, objects, and resources, each raise
> sufficient extra questions that they should be left to future RFCs where
> we can focus on each in more detail.
>
> Please read the RFC for more detail on what is and isn't proposed.
>
> Regards,
>
> --
> Rowan Tommins (n=C3=A9 Collins)
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--00000000000070f879059fdbbc29--