Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120690
Message-ID: <7C9992E3-015E-48E6-A816-0AD012CA5CAE@gmail.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_96CD1AE7-8D1D-4A44-B3D3-6BF0DA7AD932"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Date: Tue, 27 Jun 2023 10:17:35 +0200
In-Reply-To: <CAFPFaMJEByW8Wt-ppgYHxAud4GAXTvtgC4OyrK6DfNsmO=hvLQ@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
To: "G. P. B." <george.banyard@gmail.com>
References: <CAFPFaM+2eUsN9YUdUBEyr6XTe7QagyDBS8_F_LZH00ujJM8shw@mail.gmail.com>
 <72F136AA-768F-4577-80EF-22212DB50EF3@gmail.com>
 <CAFPFaMJEByW8Wt-ppgYHxAud4GAXTvtgC4OyrK6DfNsmO=hvLQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Deprecate remains of string evaluated code
 assertions
From: claude.pache@gmail.com (Claude Pache)

--Apple-Mail=_96CD1AE7-8D1D-4A44-B3D3-6BF0DA7AD932
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> Le 26 juin 2023 =C3=A0 17:05, G. P. B. <george.banyard@gmail.com> a =
=C3=A9crit :
>=20
> On Wed, 31 May 2023 at 23:20, Claude Pache <claude.pache@gmail.com =
<mailto:claude.pache@gmail.com>> wrote:
>> Although your RFC says that the `zend.assertions` ini setting has =
superseded `assert.active` for a while, the =E2=80=9Cofficial=E2=80=9D =
php.ini file still advises to modify the value of `assert.active` rather =
than the one of `zend.assertion` in order to switch behaviour at =
runtime:
>>=20
>> =
https://github.com/php/php-src/blob/91fd5641cde138b8894a48c921929b6e4abd5c=
97/php.ini-development#L1604
>>=20
>> I bet that many people (myself included) follows the advice given in =
`php.ini`.
>=20
> This talks about run-time modification, which is something that I =
don't think should be done in practice, nor is often done.

Although the specific comment in the php.ini file talks about runtime =
switching, it is in fact irrelevant whether it is set at runtime or not. =
More concretely; I use currently the settings:

* `zend.assertion=3D1` as set in the global php.ini;
* `assert.active =3D on` or `off` in my per-directory .user.ini or =
.htaccess file, depending on whether I want to enable assertions by =
default;
* optionally  `ini_set('assert.active', '1')` at runtime when I want to =
enable debug mode temporarily.

I have established the above settings several years ago (at the time of =
PHP 7), after having carefully read the documentation (and having been =
slightly confused by the redundancy between `assert.active` and =
`zend.assertion`). I might have end up to switch between `zend.assertion =
=3D 0/1` instead of switching between `assert.active =3D on/off` =
instead; I can=E2=80=99t say exactly why I chose the former option =
instead of the latter, but I guess that both the comment in the =
`php.ini` file, and the existence of `assert_options(ASSERT_ACTIVE, =
...)` as an alternative to `ini_set('assert.active', ...)`, have =
influenced my choice.

Note also that the above settings minus `zend.assertion` was the way to =
do it in PHP 5 (again it is irrelevant whether it is at runtime or not), =
and many people that used assertions in PHP 5 may have continued to use =
that way without modification, as there is currently no strong reason to =
change (only `zend.assertions=3D-1` is relevant if you are especially =
concerned about micro-optimisation).

Now, of course, people will adapt to the new settings. But given the =
confusing state of the options (both `zend.assertion` and =
`assert.active` must be enabled, and I am not even speaking about =
`assert.exception`), you ought to be super-clear (in the deprecation =
notice, in the php.ini file, in the docs), what is the the expected =
state: paradoxically leave `assert.active` and `assert.exceptions` =
enabled (the default value) even when you want to disable assertions, =
and playing exclusively with `zend.assertion`.

=E2=80=94Claude


--Apple-Mail=_96CD1AE7-8D1D-4A44-B3D3-6BF0DA7AD932--