Re: [PHP-DEV] [RFC][Under discussion] Deprecate ${} string interpolation

[Mark Baker]

On 12/03/2022 15:23, Ilija Tovilo wrote:

You're absolutely right. I will attempt to gather some numbers. For
option 3, I also think "not widely used" is just plain wrong. As for
option 4, I'm fairly confident it only exists by accident 95% of the
time.


Like Andreas, this is my biggest concern with the proposal: the lack of 
actual figures for how many libraries will be affected b the change. 
We've seen a lot of deprecations over the last year, and they always 
create some degree of pain for library/toolchain maintainers. While 
typically dismissed as "it's just a deprecation notice", and being 
accused of creating a "storm in a tea cup" whenever we raise questions, 
library maintainers are the ones who have to deal with the additional 
work when end users raise issues against their repos becase of all the 
notices they're nw seeing in their logs; who already have a lot of work 
preparing for each new release; who are expected to have fully 
eliminated any deprecations from their repos (or their dependencies) on 
or before the GA release date. How much extra work and/or stress is it 
going to give those who maintain the PHP ecosystem?


From the preparation work for the 8.0 release, there has barely been 
breathing space over the last two years; dealing with null arguments 
passed to internal functions, and other (not always docmented) changes, 
those libraries/tools take a lot of work to maintain. And with so many 
deprecations going into this release, I would like to see some risk 
assessment undertaken on the affect that each deprecation RFC will have, 
with some real figures for the number of repositories that require work 
to prepare them for the release.



--
Mark Baker

 _
|.  \ \-3
|_J_/ PHP |
|| |  __  |
|| |m|  |m|

 I LOVE PHP

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Under discussion] Deprecate ${} string interpolation

[Mike Schinkel]

> On Mar 14, 2022, at 3:20 PM, Lynn  wrote:
> 
> On Mon, Mar 14, 2022 at 8:04 PM Mike Schinkel  > wrote:
> 
> Variable variables provide functionality[1] that if removed would force major 
> rewrites of PHP applications that were architected in a way that depends on 
> that functionality. 
> And while probably between 90% and 99% of the time when someone uses variable 
> variables there are better alternatives, variable variables make certain code 
> possible that would be impossible without them. 

> Do you have examples where this is the case? 

Most of these things cannot be done without the functionality provided by 
variable variables. However a few are examples could be handled differently but 
would require significant rewrite to fix without a new 
get_value_from_variable_name() function.  Either way, these are just from the 
first few pages of those 162.2k results on SourceGraph.com 
:

https://github.com/microsoft/sql-server-samples/blob/master/samples/development-frameworks/laravel/vendor/jeremeamia/SuperClosure/src/SerializableClosure.php#L200-L208
 

https://github.com/mockery/mockery/blob/master/library/Mockery/Generator/StringManipulation/Pass/MethodDefinitionPass.php#L151
 

https://github.com/vlucas/phpdotenv/blob/master/tests/Dotenv/DotenvTest.php#L251
 

https://github.com/squizlabs/PHP_CodeSniffer/blob/master/src/Standards/PSR12/Tests/Classes/ClassInstantiationUnitTest.inc#L34-L38
 

https://github.com/kanaka/mal/blob/master/impls/php/interop.php#L19 

https://github.com/moodle/moodle/blob/master/mod/data/tests/lib_test.php#L1293 

https://github.com/moodle/moodle/blob/master/mod/data/tests/generator_test.php?L105#L104
 

https://github.com/FriendsOfPHP/PHP-CS-Fixer/blob/master/tests/Fixer/FunctionNotation/StaticLambdaFixerTest.php#L236
 

https://github.com/phpipam/phpipam/blob/master/functions/PEAR/Net/Ping.php#L284 

https://github.com/api-platform/core/blob/main/src/Core/Annotation/ApiProperty.php#L154-L159
 

https://github.com/wp-cli/wp-cli/blob/master/php/WP_CLI/Runner.php#L1285-L1287 

https://github.com/phpmyadmin/phpmyadmin/blob/master/libraries/classes/Database/Qbe.php#L878-L879
 

https://github.com/PrestaShop/PrestaShop/blob/develop/classes/SpecificPrice.php#L474
 



> Using arrays is a compatible replacement as far as I know, and I highly doubt 
> these kinds of hacks are necessary.

"Necessary" is a judgement call.  If you never do meta-programming in PHP then 
these _techniques_ — calling them "hacks" is a bit incendiary — would not ever 
seem necessary. 

However if a developer does work on projects that by-requirement leverage 
meta-programming then variable variables are a tool in one's toolkit that one 
would be hobbled without.

An area where I have seen them required is in theming where the CMS or plugin 
vendor wants to make it easier on the themer by creating dynamically-named 
variables in scope and then including a PHP file intended to be used as a 
template, and the in other functions being able to access those 
dynamically-named variables.

Other areas are in developer tools written in PHP for PHP developers.

That said, are you objecting to the "variable variable" syntax, or more broadly 
to the ability to access the value of a variable given its name (as a new 
function could provide)?

-Mike

P.S. BTW, I agree that if a developer can avoid variable variables there would 
be doing themselves and future maintainers a big favor. I am only commenting 
because in rare cases variable variables provide a capability that you cannot 
achieved another way.  But if PHP provides that other way by way of a function 
then the only 

Re: [PHP-DEV] [RFC][Under discussion] Deprecate ${} string interpolation

[Lynn]

On Mon, Mar 14, 2022 at 8:04 PM Mike Schinkel  wrote:

>
> Variable variables provide functionality[1] that if removed would force
> major rewrites of PHP applications that were architected in a way that
> depends on that functionality.
>
And while probably between 90% and 99% of the time when someone uses
> variable variables there are better alternatives, variable variables make
> certain code possible that would be impossible without them.
>

Do you have examples where this is the case? Using arrays is a compatible
replacement as far as I know, and I highly doubt these kinds of hacks are
necessary.

Re: [PHP-DEV] [RFC][Under discussion] Deprecate ${} string interpolation

[Mike Schinkel]

> On Mar 12, 2022, at 5:44 AM, Lynn  wrote:
> 
> Variable variables should be removed from PHP asap. It's 2022 and I still
> encounter bugs due to this "working" in legacy applications.



> On Mar 12, 2022, at 5:48 AM, Kamil Tekiela  wrote:
> 
> +1 on removing variable variables as soon as possible.



Variable variables provide functionality[1] that if removed would force major 
rewrites of PHP applications that were architected in a way that depends on 
that functionality. 

And while probably between 90% and 99% of the time when someone uses variable 
variables there are better alternatives, variable variables make certain code 
possible that would be impossible without them.

So, *assuming* removing variable variables is important enough to break any the 
existing code that uses it — sourcegraph.com reports[2] 162.2k examples of its 
use — PHP should at least add a function that would allow getting the variables 
value by name.  Something like `get_variable_value_by_name($name)` but 
hopefully with a less verbose name than I used in my example just now.

#jmtcw

-Mike

[1] https://stackoverflow.com/questions/16339658/php-variable-value-from-string 

[2] 
https://sourcegraph.com/search?q=context:global+lang:php+%5B%5E:%5C%5C%5D%5C%24%5C%7B%5C%24++count:all=regexp
 

[PHP-DEV] [VOTE] Undefined Variable Error Promotion

[Mark Randall]

I have started the vote for promoting undefined variable access to throw 
an Error exception.


The vote will run for 2 weeks until March 28th 2022.

https://wiki.php.net/rfc/undefined_variable_error_promotion

Mark Randall

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Under discussion] Deprecate ${} string interpolation

[BohwaZ]

> > The 4th one is very useful.
> >
> > $v = ${'param_' . $name};  
> 
> Like Rowan mentioned, the RFC does not propose to deprecate variable
> variables, just variable variables as a form of string interpolation.
> You'll still be able to use variable variables, even in strings, like
> noted above, just as form 2.

Thanks for clarifying :)

Sounds good for me then :)

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php