Re: [PHP-DEV] NULL Coercion Consistency
On 08.04.2022 19:34, Craig Francis wrote: Hi, I've written a new draft RFC to address the NULL coercion problems: https://wiki.php.net/rfc/null_coercion_consistency As a voter, I'm in favor of this RFC. I suggest to rename "Documentation" section title to "Scalars coercion inconsistency" or sth like that, as this section isn't really much about the documentation, rather the current state. -- Aleksander Machniak Kolab Groupware Developer[https://kolab.org] Roundcube Webmail Developer [https://roundcube.net] PGP: 19359DC1 # Blog: https://kolabian.wordpress.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] NULL Coercion Consistency
On Fri, Apr 8, 2022 at 10:35 AM Craig Francis wrote: > Hi, > > I've written a new draft RFC to address the NULL coercion problems: > > https://wiki.php.net/rfc/null_coercion_consistency > > This is due to the result of the Allow NULL quiz: > > https://quiz.craigfrancis.co.uk/ > > 14 votes for Fatal Type Errors irrespective of `strict_types=1`; > 13 votes for NULL coercion when not using `strict_types=1`; > 8 votes to update some parameters to allow NULL; > > I appreciate some want to force strict type checking on everyone, but I > want to make sure we have this properly documented, with names, and > explanations. > > Breaking changes should be justified - if they aren't, they only > make upgrading difficult and frustrating (bad for security). > > Craig > This RFC seems to be trying to force all PHP developers, regardless of what *they* think, to treat null as "whatever the default value is within the type context of execution", which is probably the most dangerous and bug-prone usage of null in PHP code. This would make it almost impossible for most programs to treat null instead as "an undefined value which must be explicitly set", which is another usage I commonly see in code. Given that, I think there needs to be much more justification of this change personally. Jordan
[PHP-DEV] Re: NULL Coercion Consistency
On 6 May 2022, at 16:26, Björn Larsson wrote: > Den 2022-04-08 kl. 19:34, skrev Craig Francis: >> Hi, >> I've written a new draft RFC to address the NULL coercion problems: >> https://wiki.php.net/rfc/null_coercion_consistency >> ... > > One code pattern to upgrade your code to PHP 8.1 and 9.0 is to use the > null coalescing operator like rtrim($string ?? '',...). > > If one then has a legacy codebase that works flawlessly I would say that > this path is the preferred one since it requires a minimum of work. To > dig into your code base and address why the parameter ends up like null > is probably more cumbersome. OTOH, one doesn't reap the benefits of the > "Deprecate passing null to non-nullable arguments of internal functions" > RFC since it requires to much work. > > One could argue that the "Deprecating passing null" RFC is nice, but has > a flaw when applied for existing code. Applying the null coalescing code > pattern is an easy way to make your code 8.1 compatible, but not sure if > it adds value to the application itself. > > Now if this RFC is the best way to improve things if one think this is > something of an issue with the original RFC worth addressing I don't > know. But at least worth having a discussion about! The purist within > me sighs a little when applying the code pattern above... Thanks Björn, My main concern is about backwards compatibility. If this RFC fails, I think the only way for existing code to avoid the issue will be via an automated tool, but for it to do this safely, I agree with your suggestion, I think it will need to use null coalescing (or casting via `(string) $var` or `strval($var)`) at the variable sinks... but the idea of doing that to the ~335 parameters I've listed, is, well, ugly to say the least... but I'd much rather do that, instead of having projects stuck on 8.x (where they will inevitably stop receiving security patches). I would like to know about the future benefits, and this is where my discussion with Rowan has been interesting (trying to work out the benefits vs costs)... but, tbh, I'm not really seeing a future benefit for breaking NULL coercion with internal functions (sorry). I do see benefits for consistency, and rejecting weird forms of type coercion (e.g. `htmlspecialchars(array())`), and I've tried to factor these into my RFC, but considering how NULL and an Empty String can often be seen as interchangeable (many developers giving no thought to the difference), I'm not sure how these fatal errors will help. Craig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] The future of objects and operators
Hello all, I took a while away after my operator overload RFC was declined. I've been mulling for the last few months how to move forward while respecting the concerns and feedback of those who abstained and those who voted against. But I feel like a separate discussion needs to happen first after considering many different approaches. # There is Considerable Demand For Improved Control of Operators with Objects This doesn't apply to all operators. I have not seen any comments in the last few months of digging of people who are desperate for the pow operator ( ** ) for instance. However, many people who work with math in PHP have use for at least the arithmetic operators and I see this comment frequently. Totally separate from the math domain, I've seen many comments about the desire to control the comparison operators: >, >=, ==, <=, <, !=, <>. This is something that would have numerous applications outside of mathematics, and there's even been an RFC worked on (that was declined in 2018) by Rudi to implement just comparisons. # Different Voters Have Different Concerns This is an issue that almost all RFC authors must deal with of course, but this particular subject suffers from it more severely than most. For instance, in some of the past proposals that were more limited than mine, there were comments that a full operator overloading solution should be provided instead of something halfway. However one of the comments I received more than once was that I should separate out the comparison operators into its own RFC, since those have applications outside the math domain. # Is Math A Valid Use Case? One of the more shocking (to me personally) pieces of feedback that I received from more than one person is that math is not a valid use case in PHP. I am... unsure about what to think of this opinion. I guess I would like to discuss and find out if this is widely believed among voters. # Non-Breaking Engine Changes The way that equality and comparison evaluation is done in the engine makes it impossible for certain kinds of overloading to be done, even in extensions. This isn't because that was an intended restriction, I discussed this issue with CMB and provided a PR a few months ago to resolve this, however it has remained in limbo: https://github.com/php/php-src/pull/7973 # Overall Vision I'm not sure at this point how voters think objects and operators should work together into the future. I'd like to see if anyone is willing to have high-level discussion about the ideas, instead of picking at the implementation or details of a particular RFC. Jordan
[PHP-DEV] Re: [VOTE] Undefined Property Error Promotion
On 21/04/2022 22:45, Mark Randall wrote: I have now opened voting on Undefined Property Error Promotion. https://wiki.php.net/rfc/undefined_property_error_promotion The vote has concluded. The RFC has been passed with 31 votes (86%) in favour, 5 against. -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: NULL Coercion Consistency
Den 2022-04-08 kl. 19:34, skrev Craig Francis: Hi, I've written a new draft RFC to address the NULL coercion problems: https://wiki.php.net/rfc/null_coercion_consistency This is due to the result of the Allow NULL quiz: https://quiz.craigfrancis.co.uk/ 14 votes for Fatal Type Errors irrespective of `strict_types=1`; 13 votes for NULL coercion when not using `strict_types=1`; 8 votes to update some parameters to allow NULL; I appreciate some want to force strict type checking on everyone, but I want to make sure we have this properly documented, with names, and explanations. Breaking changes should be justified - if they aren't, they only make upgrading difficult and frustrating (bad for security). Craig Hi, Have been busy for a while and haven't followed all the details around this RFC, but now back on track. One code pattern to upgrade your code to PHP 8.1 and 9.0 is to use the null coalescing operator like rtrim($string ?? '',...). If one then has a legacy codebase that works flawlessly I would say that this path is the preferred one since it requires a minimum of work. To dig into your code base and address why the parameter ends up like null is probably more cumbersome. OTOH, one doesn't reap the benefits of the "Deprecate passing null to non-nullable arguments of internal functions" RFC since it requires to much work. One could argue that the "Deprecating passing null" RFC is nice, but has a flaw when applied for existing code. Applying the null coalescing code pattern is an easy way to make your code 8.1 compatible, but not sure if it adds value to the application itself. Now if this RFC is the best way to improve things if one think this is something of an issue with the original RFC worth addressing I don't know. But at least worth having a discussion about! The purist within me sighs a little when applying the code pattern above... r//Björn L -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: Request for wiki karma
On 06.05.2022 at 05:03, Juliette Reinders Folmer wrote: > As per the progression of the discussion about the deprecated partially > supported callable, a new RFC is needed to expand the scope of the > deprecations. See: https://externals.io/message/117342 > > I'd like to request karma to create this RFC. > > Username: jrf RFC karma granted. Best of luck! :) -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
