> Le 29 août 2023 à 15:19, Saki Takamachi <s...@sakiot.com> a écrit :
>
>> Hi,
>>
>> The larger issue is that higher-order functions do not inherit the
>> `strict_types` mode from its calling code, and this is not specific to
>> internal functions.
>>
>> If you intend to change that for internal functions (with proper deprecation
>> period, of course), you might consider making such a behaviour also possible
>> for userland functions (probably using some opt-in); so that future
>> higher-order internal functions do not become impossible to polyfill.
>>
>> —Claude
>
> Hi, thank you for confirming.
>
> If you simply put the problem you pointed out in the code, would it be
> something like this?
> https://gist.github.com/SakiTakamachi/8292dbfe92a2029a6c7b506b12296b7d
>
> Admittedly, I don't think this is intuitive either.
That might not be intuitive to you, but it follows directly from the specified
semantics: whether a function is called in `strict_types` mode or not, depends
only on where the function is called. I personally doubt that there is an easy
way to adjust the rule in order to make it both “intuitive” and simple.
>
> [...]
>
> When considering the inheritance of strict_types, I think that it should be
> an attribute that can be set in “php.ini" instead of being specified for each
> file.
>
> What do you think?
Beware that there are many third-party packages that have not opted for
`strict_types=1`; if you enable that mode globally, you might make those
packages malfunction.
As I have just checked, among the packages I’ve installed via composer, there
are more packages that do not use `strict_types=1`, than packages that use it.
Among those that don’t use `strict_types`, the following ones are fairly common:
google/apiclient
league/oauth2-client
michelf/php-markdown
microsoft/microsoft-graph
phpmailer/phpmailer
phpoffice/phpspreadsheet
phpseclib/phpseclib
—Claude
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
