Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On Tue, Feb 22, 2022 at 2:53 PM Nicolas Grekas wrote: > > But this makes me think: we should trigger a deprecation just before all > corresponding warnings! > Please, no more deprecation warnings, make it stop 😥 Yes, undefined variables are a problem, but I just spent 6 months in `vendor/` code for 8.0->8.1 stuff, and it doesn't bring anything but frustration: this stuff is statically introspectible, and even more side-effects are just more trouble. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.io/
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
Le mar. 22 févr. 2022 à 12:07, Mark Randall a écrit : > On 22/02/2022 09:15, Nicolas Grekas wrote: > > I very much call for an implementation to be provided before starting any > > vote on the topic btw. > The RFC states on its first line that accessing an undefined variable > emits an E_WARNING. If it does not currently emit an E_WARNING then it > is out of scope of this RFC. > This last sentence could be worth copy/pasting into the RFC :) Thanks for the recent edits, they help clarify to me. > It is not sensible to provide a full implementation for something that > will require extensive engine and test changes for something several > years into the future, during which many other changes will be made. > > A sensible time for this would be after the branch is cut for 8.4. > I understand if the target is to do everything in 9.0. But this makes me think: we should trigger a deprecation just before all corresponding warnings! This would signal the change to 8.x users and help them spot where a change is needed. This should happen before the warning to that error handlers that turn the warning into an exception also get a note about the soon-to-be change. WDYT? Nicolas
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
I have tried to no avail to be removed from this list. So I will just spam this until I am removed. On Tue, Feb 22, 2022, 3:15 AM Nicolas Grekas wrote: > Le ven. 18 févr. 2022 à 12:24, Rowan Tommins a > écrit : > > > On 17/02/2022 23:28, Mark Randall wrote: > > > I present: > > > > > > https://wiki.php.net/rfc/undefined_variable_error_promotion > > > > > > It would be good to have a "Scope" or "Unaffected Functionality" section > > here, because there are a number of closely related things which were > > also raised from Notice to Warning in 8.0: > > > > - undefined array keys > > - undefined object properties > > - array access on a non-array > > - property access on a non-object > > > > I think it is sensible to discuss those separately, but it would be good > > to make that clear. > > > > > > Similarly, it would be good to have more discussion of what "accessing" > > means, as the current examples are quite narrow, only showing direct use > > and the ++ operator. Other functionality potentially affected: > > > > - passing the variable to a function, presumably excluding by-reference > > parameters which don't currently warn > > - all the combined assignment operators - > > https://www.php.net/manual/en/language.operators.assignment.php > > - the array append operator ($a[] = 42;) does NOT currently give an > > undefined variable Warning > > - variable variables, e.g. "$b = 'a'; echo $$b;" > > - the compact() pseudo-function > > > > There's probably others that I've missed. > > > > I 100% agree with that. An "Unaffected Functionality" section would be much > welcome. > > I would add to the list: isset($foo) when $foo is first seen. > (To me this should not throw anything, like for uninitialized properties.) > > If the RFC is about promoting the current warnings to Error without adding > any other Error at places that currently don't throw any warnings, then it > could be useful to say so. And if the RFC is going to propose to throw > Error at places that are currently warning-less, the list should be > explicit. > > I very much call for an implementation to be provided before starting any > vote on the topic btw. > This is typically the kind of topic where getting into the actual code > might help spot edge cases. > > Thanks for the RFC btw! > > Nicolas >
Re: [PHP-DEV] [VOTE] Redacting parameters in back traces
Hi Internals! On 2/9/22 14:02, Tim Düsterhus, WoltLab GmbH wrote: "Redacting parameters in back traces" [2] […] 2022-02-23 at 13:30 UTC […] [2] https://wiki.php.net/rfc/redact_parameters_in_back_traces I'm not sure if a vote-closing reminder is required by the process, some RFC had one, some didn't. So to be on the safe side: As a reminder: Voting for the "Redacting parameters in back traces" RFC closes in a little more than 25 hours. Best regards Tim Düsterhus Developer WoltLab GmbH -- WoltLab GmbH Nedlitzer Str. 27B 14469 Potsdam Tel.: +49 331 96784338 duester...@woltlab.com www.woltlab.com Managing director: Marcel Werk AG Potsdam HRB 26795 P -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 18/02/2022 11:23, Rowan Tommins wrote: - undefined array keys - undefined object properties - array access on a non-array - property access on a non-object I'd encourage those to be discussed, but they are unrelated to this RFC. I think most of them would pass fairly easily, but undefined array keys is out the outlier and has a reasonable chance of being rejected at this time. However, with their being 4 years before the launch of 9.0 (and the next opportunity to change it) opinion may change between now and then. I've updated the RFC to define accessing a variable as attempting to read its value for use in an expression without accounting for the possibility of it being unset. I have also included the warning message to narrow this down further, and noted that things which account for undefined variables such as isset, empty and null coalesce will remain unaffected. If there's am existing formal definition someone wishes to contribute, I'd be happy to update it. One thing maybe worth mentioning is that while most operators such as ++, +=, .= etc will be covered by this change, $undefined[] = 1; will not be. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 22/02/2022 09:15, Nicolas Grekas wrote: I very much call for an implementation to be provided before starting any vote on the topic btw. The RFC states on its first line that accessing an undefined variable emits an E_WARNING. If it does not currently emit an E_WARNING then it is out of scope of this RFC. It is not sensible to provide a full implementation for something that will require extensive engine and test changes for something several years into the future, during which many other changes will be made. A sensible time for this would be after the branch is cut for 8.4. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
Le ven. 18 févr. 2022 à 12:24, Rowan Tommins a écrit : > On 17/02/2022 23:28, Mark Randall wrote: > > I present: > > > > https://wiki.php.net/rfc/undefined_variable_error_promotion > > > It would be good to have a "Scope" or "Unaffected Functionality" section > here, because there are a number of closely related things which were > also raised from Notice to Warning in 8.0: > > - undefined array keys > - undefined object properties > - array access on a non-array > - property access on a non-object > > I think it is sensible to discuss those separately, but it would be good > to make that clear. > > > Similarly, it would be good to have more discussion of what "accessing" > means, as the current examples are quite narrow, only showing direct use > and the ++ operator. Other functionality potentially affected: > > - passing the variable to a function, presumably excluding by-reference > parameters which don't currently warn > - all the combined assignment operators - > https://www.php.net/manual/en/language.operators.assignment.php > - the array append operator ($a[] = 42;) does NOT currently give an > undefined variable Warning > - variable variables, e.g. "$b = 'a'; echo $$b;" > - the compact() pseudo-function > > There's probably others that I've missed. > I 100% agree with that. An "Unaffected Functionality" section would be much welcome. I would add to the list: isset($foo) when $foo is first seen. (To me this should not throw anything, like for uninitialized properties.) If the RFC is about promoting the current warnings to Error without adding any other Error at places that currently don't throw any warnings, then it could be useful to say so. And if the RFC is going to propose to throw Error at places that are currently warning-less, the list should be explicit. I very much call for an implementation to be provided before starting any vote on the topic btw. This is typically the kind of topic where getting into the actual code might help spot edge cases. Thanks for the RFC btw! Nicolas
