Re: [PHP-DEV] Proposal: php.ini environment variable fallback value
PHP's ini values are already a bit of a mess. You have a global php.ini
file, and then most PHP ini directives can be set per directory using the
.htaccess file. About a third can be set at runtime. This makes tracking
down where a setting came from a bit of a headache unless care is taken.
This proposal promises to make the situation even more complicated.
Also, what would this solve that using .htaccess files to override the
default values not solve aside from the rare settings that cannot be set
per directory?
On Fri, Jul 24, 2020 at 3:54 PM Derek Bonner wrote:
> Currently an environment variable can be specified in the php.ini file.
> This is useful if you want tune one or two settings in your runtime
> environment. Where this runs into issues is if you want to do something
> similar to Juan Terminio[1][2].
>
> I'm proposing a change the php.ini parser that would allow for an extended
> syntax for environment variables in the php.ini. In this syntax when
> checking for an environment variable if it is empty the fallback value
> would be used instead. The original environment variable syntax would
> remain valid as well.
>
> Possible syntax options. I currently do not have a very deep understanding
> of the current .ini parser so this may make invalid assumptions.
>
> * memory_limit = ${PHP_MEMORY_LIMIT:-"default value"}
> * memory_limit = ${PHP_MEMORY_LIMIT::"default value"}
> * memory_limit = ${PHP_MEMORY_LIMIT:="default value"}
> * memory_limit = ${PHP_MEMORY_LIMIT=="default value"}
>
> * Potential issue: Adopting a bash-ism
>
> This type of environment fallback is common in bash. If adopted it could
> lead users to think other bash features are also available. To dissuade
> this I would suggest that the fallback value syntax not appear in any of
> the default php.ini files. Users must read the documentation and decide if
> it works for them and add it in their php.ini file.
>
> Changes needed in the code
>
> Digging through the code I find that two sections would need to be changed,
> both in Zend/zend_ini_parser.y. I hope to be able to write this code myself
> but would gladly accept some guidance.
>
> 1. cfg_var_ref: Currently TC_DOLLAR_CURLY TC_VARNAME '} would need to be
> changed to something like TC_DOLLAR_CURLY TC_VARNAME ':-' TC_FALLBACK '}'
> 2. zend_ini_get_var: I imagine this would require adding a third parameter
> to the function signature that would be used in the event of a null value
> when checking the environment.
>
> [1]
> https://jtreminio.com/blog/php-modules-toggled-via-environment-variables/
> [2]
>
> https://jtreminio.com/blog/docker-php/php-fpm-configuration-via-environment-variables/
>
> I look forward to your feedback.
>
> Derek
>
Re: [PHP-DEV] Proposal: php.ini environment variable fallback value
On Sat, Jul 25, 2020 at 9:30 AM Chuck Adams wrote: > > Not a fan of special syntax for environment variables regardless of > the syntax. I think `$_ENV['foo'] ?? 'bar'` is fine as-is. Not so > much the superglobal, but there's also getenv(). I feel fairly silly, this being for just .ini files. Seems reasonable enough there, though now we're talking about .ini files no longer being static... --c -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Ternary associativity
Hey, Björn Larsson wrote: Would it then make sense to have it as compile time error in 8.0 and make it right-associativein in e.g. 8.1? OTOH, when looking in RFC on top 1000 affected composer packages it looks like having the change in 8.0 might be a way forward... r//Björn L I think 7.4 and 8.1 are too close to eachother, only two versions apart. There's probably a lot of people out there who don't upgrade PHP version yearly, so they might write 7.4 code and then hop over to 8.1, and oops, it's silently broken! I see other threads suggesting changing in 9.x which seems less problematic, I guess. Regards, Andrea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] wiki.php.net DokuWiki version
Hey everyone, I assume others with php.net accounts also see these messages when logged into wiki.php.net: > New release candidate 3 available: 2020-06-09 "Hogfather". upgrade now! [51.2] (what's this?) > > New release candidate 2 available: 2020-06-01 "Hogfather". upgrade now! [51.1] (what's this?) > > New release candidate available: 2020-06-01 "Hogfather". upgrade now! [51] (what's this?) > > Hotfix release available: 2018-04-22c "Greebo". upgrade now! [50.3] (what's this?) I don't suppose there's any rush to upgrade to the latest and greatest, but “hotfix release available” sounds a little concerning? Regards, Andrea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Ternary associativity
On 25/07/2020 16:26, Chuck Adams wrote: On Fri, Jul 24, 2020 at 1:32 PM Rowan Tommins wrote: If anything, I would argue for making both of these into errors, if that's possible. I think the biggest risk with this kind of change is not existing code relying on the old behaviour, it is code relying on the *new* behaviour which is accidentally run on older versions of PHP. I thought the proposal to turn unparenthesized use into a warning then waiting for PHP9 to use the proper precedence was the right idea. Nested ternaries with the proper precedence turn into lovely truth tables, which isn't even an uncommon idiom in C. I'd really not like to feed /r/lolphp ammo by requiring the parens in all cases and continuing to break the ternary operator in comparison with every other language that has it. I think we're talking at cross-purposes here; I'm not saying it should throw an error forever, I'm saying it should throw an error in PHP 8.x, and have new behaviour in 9.x, which as I understand it is the current plan. Nikita is suggesting that it should instead change behaviour immediately in PHP 8.x, so that the below code would be valid in both PHP 7.4 and 8.0, but with a different outcome: $enableFoo = $config['foo']['enabled'] ? true : $config['foo']['disabled'] ? false : $config['default_enabled'] ? true : false; I think there is too high a risk that a library would include that code intending the new behaviour, while claiming support for PHP 7.x, thus introducing a subtle and confusing bug. The same risk applies to the concatenation case Nikita mentioned, which concerns code like this: $priceLabel = $currencySymbol . $price + $tax; Since PHP 7.4 detects the affected situations and raises an E_DEPRECATED, I think it would be safer to detect them and throw an error in PHP 8.x, rather than immediately changing behaviour. In both cases, the correct behaviour can safely be added in PHP 9.0, since it's incredibly unlikely that code will be run on both 9.0 and 7.x, but never on 8.x Regards, -- Rowan Tommins (né Collins) [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: php.ini environment variable fallback value
On Fri, Jul 24, 2020 at 2:54 PM Derek Bonner wrote:
> * memory_limit = ${PHP_MEMORY_LIMIT:-"default value"}
> * memory_limit = ${PHP_MEMORY_LIMIT::"default value"}
> * memory_limit = ${PHP_MEMORY_LIMIT:="default value"}
> * memory_limit = ${PHP_MEMORY_LIMIT=="default value"}
Not a fan of special syntax for environment variables regardless of
the syntax. I think `$_ENV['foo'] ?? 'bar'` is fine as-is. Not so
much the superglobal, but there's also getenv().
--c
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Ternary associativity
On Fri, Jul 24, 2020 at 1:32 PM Rowan Tommins wrote: > If anything, I would argue for making both of these into errors, if > that's possible. I think the biggest risk with this kind of change is > not existing code relying on the old behaviour, it is code relying on > the *new* behaviour which is accidentally run on older versions of PHP. I thought the proposal to turn unparenthesized use into a warning then waiting for PHP9 to use the proper precedence was the right idea. Nested ternaries with the proper precedence turn into lovely truth tables, which isn't even an uncommon idiom in C. I'd really not like to feed /r/lolphp ammo by requiring the parens in all cases and continuing to break the ternary operator in comparison with every other language that has it. --c -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [VOTE] zend.exception_string_param_max_len: Configurable string length in getTraceAsString()
Hi internals, https://wiki.php.net/rfc/throwable_string_param_max_len has been accepted and merged, with 36 votes in favor and 2 votes against it. Thanks, - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
