Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121537
Message-ID: <ca92f7f5-7c32-4518-b8d6-4cb02b3e4e73@gmail.com>
Date: Mon, 30 Oct 2023 22:54:30 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-GB
To: internals@lists.php.net
References: <CAM2mkbRmcwG8C_Y6Jxdr8Me1N8Cu06JqFdPKtKjJZ9msRy_LRw@mail.gmail.com>
In-Reply-To: <CAM2mkbRmcwG8C_Y6Jxdr8Me1N8Cu06JqFdPKtKjJZ9msRy_LRw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] New RFC : empty() function
From: rowan.collins@gmail.com (Rowan Tommins)

On 30/10/2023 12:24, Alessandro Rosa wrote:
> I have posted a new RFC at this link 
> https://wiki.php.net/rfc/empty_function where I suggested some 
> improvements to the standard built-in empty() function and provided a 
> number of examples.


Hi, and welcome!


First, regarding the clarity of the proposal.

You have a few pieces of sample code in the RFC, but the "expected 
value" comments don't actually match what that code would output. Rather 
than inline comments on each line, I suggest you give the current output 
of the whole code, followed by the expected / desired output. I would 
also suggest replacing "<br/>" with "\n", to keep the code smaller.

Similarly, your PHP-implemented version of the function is trying to be 
far too clever. If you want to illustrate what you think the rules 
should be, you need a clear, well-commented function implementing those 
rules. The first if statement, for instance, is just a very confusing 
way to write "if ( $input === null ) { return true; }"

Neither style of example really explains why you think your proposed 
rules make sense. *Why* should boolean true be considered empty? In what 
situation would you call the function with no arguments and expect a 
meaningful response?


Second, regarding timescales.

As documented at https://wiki.php.net/rfc/releaseprocess the official 
policy of the project is that backwards compatibility can only be broken 
in a major version - that is, the next chance to break compatibility is 
in 9.0, not 8.anything. While there are often grey areas around this 
rule, there is absolutely no question that empty() could be removed any 
time before that. If anything, proposing removal in 10.0 might be more 
reasonable.


Regards,

-- 
Rowan Tommins
[IMSoP]