On Tuesday 02 May 2023 15:07:21 (+02:00), Rowan Tommins wrote:
> On Tue, 2 May 2023 at 13:20, Máté Kocsis wrote:
>
> > Yes, I agree that the assert_options() name is at least weird but I
> > wouldn't like to
> > include changes into this RFC which are not strictly related to overloaded
> > signatures. Just like in case of implode(), the 1-parameter version of
> > assert_options()
> > could be added to the PHP 8.3/8.4 deprecations RFC though.
> >
>
>
> It *is* strictly related, though: the current function has two purposes:
> get an option, and set an option; the RFC proposes to split that into two
> functions, and there are three ways we can do that:
>
> 1) Keep the current name for get, come up with a new name for set
> 2) Come up with a new name for get, keep the current name for set
> 3) Come up with new names for both get and set
>
> I then looked further, and suggested:
>
> 4) Deprecate the existing function, but do not create any new functions;
> instead, recommend ini_get for get, and ini_set for set
>
> All four options are direct remedies to the overloaded signature, and I
> think due to the current unclear naming, options 3 and 4 are superior to
> options 1 and 2. Do you have a specific reason to prefer option 1?
I can't answer that question but checked especially option 4) as it looked
promising to me.
In the overall context, let's not forget this note [1]:
> While assert_options() can still be used to control behaviour as described
> above for backward compatibility reasons, PHP 7 only code should use the two
> new configuration directives to control the behaviour of assert() and not
> call assert_options().
That is zend.assertions and assert.exception only (of which only the second has
a counterpart in ASSERT_EXCEPTION as the first can not be set at runtime).
That means: Before investing too much thought which of all the options, IMHO
the general route should be to deprecate assert_options() overall to prepare
its removal (and with it a good share of the assert.options).
>From signature / types perspective, ASSERT_CALLBACK option is not 100%
>compatible w/ ini_get()/ini_set() as they don't support all types of the
>callback pseudotype. but have not double checked this as I ran over the above
>mentioned remark which I believe should be leading (the deprecation of the pre
>PHP 7.0 assert/options alltogether).
With the PHP 8.0 release this got some traction (upgrade of the assert callback
signature and ASSERT_QUIET_EVAL option seems to be gone (perhaps in alignment
with the improvements in the error handler callback signature on the level
parameter that is now the error type regardless of error_level())).
So perhaps this for the current RFC:
4) Deprecate the existing function, but do not create any new functions;
instead, recommend the two configuration settings zend.assertions and
assert.exception only, for those that can be set at runtime recommend
ini_get()/ini_set(), for callback further investigate (does it still work?),
for the moment I see no alternative to assert_options() for callback values not
of type null or string (e.g. callabe array or callable object) as those are not
supported by ini_get()/in_set().
-- hakre
p.s. thank you for creating this RFC and taking care.
[1]: https://www.php.net/manual/en/function.assert.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
