Re: [RFC] Deprecate remains of string evaluated code assertions

From: Date: Tue, 27 Jun 2023 08:17:35 +0000
Subject: Re: [RFC] Deprecate remains of string evaluated code assertions
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-120690@lists.php.net to get a copy of this message
> Le 26 juin 2023 à 17:05, G. P. B. <george.banyard@gmail.com> a écrit : > > 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 “official” 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: >> >> >> https://github.com/php/php-src/blob/91fd5641cde138b8894a48c921929b6e4abd5c97/php.ini-development#L1604 >> >> I bet that many people (myself included) follows the advice given in >> php.ini. > > 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=1 as set in the global php.ini; * assert.active = 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 = 0/1 instead of switching between assert.active = on/off instead; I can’t 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=-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. —Claude

« previous php.internals (#120690) next »