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

[Rowan Tommins]

On 15/03/2022 23:02, Patrick ALLAERT wrote:

This is not far from the reason why I voted "no".

I am not against the fact this warning becomes an error per se. I am just
not very fan of cherry-picking an individual kind of problem (read:
notice/warning/error/...) and changing it without a more global frame.



I have also voted no for similar reasons: the scope of this RFC appears 
to be "all the places that are convenient", rather than "all the places 
that are covered by the claimed rationale".


I think it is sensible to raise an error for the kind the kind of 
"undefined foo" that is almost certainly a typo. I think we should be 
more cautious about the kind that could be lazy but intentional dynamic 
access. I would have voted Yes to an RFC which defined its scope in such 
terms.


The language does not currently make that distinction consistently, and 
I don't think we should be planning an error on a basis as vague as 
"wherever we currently have a warning".



For instance, in-place increment is covered, but array append is not:

$undefined++; // Warning, planned Error
$undefined[] = 1; // completely silent

Similarly, variable-variables are covered, even though they are more 
similar to array keys, which are not:


$foo = 'undefined'; $$foo++; // covered by RFC
$array = []; $key = 'undefined'; $array[$key]++; // not covered by RFC

None of this is even mentioned in the RFC, let alone justified.


Regards,

--
Rowan Tommins
[IMSoP]

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

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

[Christian Schneider]

Am 16.03.2022 um 11:39 schrieb Mark Randall :
> On 16/03/2022 09:17, Christian Schneider wrote:
>> Maybe we should ask ourselves the question: Why would the entire package be 
>> blocked? Just because it is too big or maybe there *are* subtleties which 
>> have not been properly resolved?
> 
> It's politics and the practicalities of getting things done.

A nice description of salami slicing tactics ;-)

> An all-or-nothing approach will inevitably end up with nothing, because those 
> who are opposed on principle need only rally around attacking the weakest 
> element, without the need to address any of the other parts which might 
> individually be much stronger.
> 
> That's not to say that the weakest elements shouldn't be debated, they should.
> 
> But we shouldn't sabotage ourselves, and bring about a state of permanent 
> project paralysis, by mandating that semi-related weaker changes are bundled 
> with stronger ones and must be voted on as a whole.
> 
> It would just open the door to the constant use of a poison pill argument.


The problem is you are saying "the weakest should be debated but not right now, 
let's move forward anyway" and you are also stipulating that the changes are 
only semi-related.

By doing that you're dismissing Patrick's notion that they are more closely 
related than you acknowledge because he's saying having inconsistent handling 
of undefined stuff is also a WTF.

And at the same time I really hope once we start discussing undefined array 
indices you won't bring up consistency with undefined variables (and possibly 
object properties) as the reason to change it. That would feel weird given that 
you want to treat them as separate issues right now ;-)

- Chris

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

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

[Mark Randall]

On 16/03/2022 09:17, Christian Schneider wrote:

Maybe we should ask ourselves the question: Why would the entire package be 
blocked? Just because it is too big or maybe there *are* subtleties which have 
not been properly resolved?


It's politics and the practicalities of getting things done.

An all-or-nothing approach will inevitably end up with nothing, because 
those who are opposed on principle need only rally around attacking the 
weakest element, without the need to address any of the other parts 
which might individually be much stronger.


That's not to say that the weakest elements shouldn't be debated, they 
should.


But we shouldn't sabotage ourselves, and bring about a state of 
permanent project paralysis, by mandating that semi-related weaker 
changes are bundled with stronger ones and must be voted on as a whole.


It would just open the door to the constant use of a poison pill argument.

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

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

[Christian Schneider]

Am 16.03.2022 um 10:00 schrieb Mark Randall :
> On 15/03/2022 23:02, Patrick ALLAERT wrote:
>> I am not against the fact this warning becomes an error per se. I am just
>> not very fan of cherry-picking an individual kind of problem (read:
>> notice/warning/error/...) and changing it without a more global frame.
> 
> I think we should try to hit all of them, ideally in time for PHP 9.
> 
> That was the premise behind: https://externals.io/message/116918
> 
> It will likely take several RFCs until we've got it in the state we want it, 
> some of those are more contentious than others (such as undefined array 
> indexes).
> 
> I think undefined property access should throw too, and will likely have 
> supermajority support, but let's do it in a separate RFC.
> 
> What I don't think we want is the entire package being blocked because a 
> particular item (i.e. array keys) is contentious.


This is actually exactly what Patrick is complaining about: No global plan.

I know I'm on the "losing" side of this discussion but sometimes it feels like 
one of the main arguments is "we already changed this and that to exceptions, 
now we have to do it in this case too". Which, to me, fits the first paragraph 
of https://en.wikipedia.org/wiki/Salami_slicing_tactics

Maybe we should ask ourselves the question: Why would the entire package be 
blocked? Just because it is too big or maybe there *are* subtleties which have 
not been properly resolved?

- Chris

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

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

[Mark Randall]

On 15/03/2022 23:02, Patrick ALLAERT wrote:

I am not against the fact this warning becomes an error per se. I am just
not very fan of cherry-picking an individual kind of problem (read:
notice/warning/error/...) and changing it without a more global frame.


I think we should try to hit all of them, ideally in time for PHP 9.

That was the premise behind: https://externals.io/message/116918

It will likely take several RFCs until we've got it in the state we want 
it, some of those are more contentious than others (such as undefined 
array indexes).


I think undefined property access should throw too, and will likely have 
supermajority support, but let's do it in a separate RFC.


What I don't think we want is the entire package being blocked because a 
particular item (i.e. array keys) is contentious.


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

Re: [PHP-DEV] Deprecated partially supported callables: should is_callable() throw a deprecation notice ?

[Christian Schneider]

Am 16.03.2022 um 06:52 schrieb Juliette Reinders Folmer 
:
> I've just been looking in detail at the Partially Supported Callables 
> deprecation RFC: 
> https://wiki.php.net/rfc/deprecate_partially_supported_callables
> 
> The RFC explicitly excludes the `is_callable()` function and the `callable` 
> type from throwing deprecation notices.
> 
>> The |is_callable()| function and |callable| type remain side-effect free and 
>> do not throw a deprecation warning. They will continue to accept these 
>> callables until support is removed entirely. 
> 
> While I can fully support this for the `callable` type, I wonder if the 
> decision to not throw a deprecation on use in `is_callable()` is the right 
> one (though I understand the desire to keep it side-effect free).
> 
> Consider these code samples:
> 
>  function foo(callable $callback) {}
>  foo('static::method');
> 
> This function call not throwing a deprecation is not problematic as in PHP 
> 9.0 the function will start throwing a TypeError.

My reaction to your last sentence is actually quite the opposite: This is a 
major problem because code which was "just working" directly goes to a 
TypeError without a migration phase warning about it. This is something I've 
repeatedly advocated against.

>  if (is_callable('static::method')) {
>  static::method();
>  }
> 
> The second code sample, however, is problematic, as in PHP 9.0, the behaviour 
> of this code will be silently reversed for those callbacks which would 
> previously result in `is_callable()` returning true, which makes this a 
> potentially dangerous change without deprecation notice.

I agree with you here: Code which silently changes behavior is also a migration 
hassle.

- Chris

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

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

[Christian Schneider]

Am 15.03.2022 um 20:07 schrieb Miguel Rosales :
> Christoph M. Becker wrote on 15/3/22 19:17:
>> That explicitly excludes undefined array indexes, and apparently also
>> excludes undefined properties (which raise "Warning: Undefined property:")
>> 
> AFAIU error promotion for undefined properties has already been covered by 
> the Deprecate Dynamic Properties RFC 
>  >, which will start 
> throwing errors in 9.0.

That RFC covers the *creation* of undefined properties, not the *reading* of 
undefined properties.

- Chris