Hi,
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.
Thanks,
Alessandro Rosa
WEB : http://alessandrorosa.altervista.org
LINKEDIN : https://www.linkedin.com/in/alessandro-rosa-9b7ba67b/
Hi,
I don't understand what you are proposing and what problem you are trying
to fix. The RFC is not explaining things well.
Hi,
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.
Forget about deprecating empty(). No chance I'd vote for that. The RFC
is not clear either.
--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]
PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
Hello,
I understand that the idea of the RFC is about some behaviors of
empty(), e.g.:
var_dump(empty($var)); // true $var= 0; var_dump(empty($var)); // true
var_dump(empty($empty)); // true $var= true; var_dump(empty($var)); //
false, $varis defined and has value $str = false; var_dump(empty($var));
// true, $varis defined and has value ```
According to the manual: “determine whether a variable is empty”.
However, according to my example, the variable is defined and has its
value as 0 or false, and empty() returns true anyway. I confess that
I've had some problems like this, and we chose not to use empty(), as
sometimes 0 or false makes sense as a valid value.
Also, having is_empty() would be nice, but keeping it empty, otherwise
there would be a huge break.
Maybe think of a strict empty() mode? Even so, it would change behavior.
Sorry if I didn't understand the discussion correctly.
However, according to my example, the variable is defined and has its
value as 0 or false, and empty() returns true anyway. I confess that
I've had some problems like this, and we chose not to use empty(), as
sometimes 0 or false makes sense as a valid value.
That is exactly as the documentation explains it.
empty is to check if a variable is not holding a usable value.
0, false, true are all valid values and show the variable is not
empty.
The purpose for empty is to check for undefined variables, empty
arrays or empty strings.
eg. "", [], null or undefined.
However, according to my example, the variable is defined and has its
value as 0 or false, and empty() returns true anyway. I confess that
I've had some problems like this, and we chose not to use empty(), as
sometimes 0 or false makes sense as a valid value.That is exactly as the documentation explains it.
empty is to check if a variable is not holding a usable value.
0, false, true are all valid values and show the variable is not
empty.The purpose for empty is to check for undefined variables, empty
arrays or empty strings.
eg. "", [], null or undefined.
This is exactly where the problem lies. Is a string with just whitespace
empty? Why would an ArrayObject with count 0 not be considered to be empty
while an array with count 0 is? "empty" is subjective and therefore not a
reliable function to use. Especially in legacy code I find that people use
empty where they should've been using count() === 0 and have resulted
in bugs that weren't discovered until months or years later. The variations
of $a === '', count($a) === 0, ! isset($a), and $a === null already
check all the scenarios you need, without risking funky bugs due to how the
internal check for "falsy" values works.
Thanks everybody for joining this discussion.
I appreciated a lot the points you raised, as they are helping me to
update and improve my rfc,
whose meaning, as I hope, would look clearer than the earlier version.
Alessandro
Il giorno lun 30 ott 2023 alle ore 16:36 Lynn kjarli@gmail.com ha scritto:
However, according to my example, the variable is defined and has its
value as 0 or false, and empty() returns true anyway. I confess that
I've had some problems like this, and we chose not to use empty(), as
sometimes 0 or false makes sense as a valid value.That is exactly as the documentation explains it.
empty is to check if a variable is not holding a usable value.
0, false, true are all valid values and show the variable is not
empty.The purpose for empty is to check for undefined variables, empty
arrays or empty strings.
eg. "", [], null or undefined.This is exactly where the problem lies. Is a string with just whitespace
empty? Why would an ArrayObject with count 0 not be considered to be empty
while an array with count 0 is? "empty" is subjective and therefore not a
reliable function to use. Especially in legacy code I find that people use
emptywhere they should've been usingcount() === 0and have resulted
in bugs that weren't discovered until months or years later. The variations
of$a === '',count($a) === 0,! isset($a), and$a === nullalready
check all the scenarios you need, without risking funky bugs due to how the
internal check for "falsy" values works.
This is exactly where the problem lies. Is a string with just whitespace
empty? Why would an ArrayObject with count 0 not be considered to be empty
while an array with count 0 is? "empty" is subjective and therefore not a
reliable function to use. Especially in legacy code I find that people use
emptywhere they should've been usingcount() === 0and have resulted
in bugs that weren't discovered until months or years later. The variations
of$a === '',count($a) === 0,! isset($a), and$a === nullalready
check all the scenarios you need, without risking funky bugs due to how the
internal check for "falsy" values works.
trust me, Ive worked on some terrible code bases that do
exactly that and have variables redefined or dynamically assigned
and you have to really check if it has been assigned a value or
not and what value.
It might be forgotten by everyone because of how far PHP has come
but there is still extensive use of the @ suppressor and the
alternative to empty would be
if (@$var == "" || @$var == null || @$var == [] || count(@$var) == 0){}
empty() is 1 of 3 functions i believe that does not throw an undefined
variable warning if you don't @ suppress the variable you are passing in.
So if you want to get rid of empty, can we reignite the talks to finally
get rid of @
Thanks everybody for joining this discussion.
I appreciated a lot the points you raised, as they are helping me to
update and improve my rfc,
whose meaning, as I hope, would look clearer than the earlier version.
Improvements must be achieved, whatever they would cost.
Ambiguities shall be resolved. I think this is the first principle in
computer science: 0 or 1 ! :-D
In any case, they are not assumed to be resort into cut-off transitions:
they may be achieved within 3, 4 or 5 versions.
Don't be scared.
I have implemented my version in my own library and it works like a charm:
you'll have exactly what you read.
Alessandro Rosa
Il giorno lun 30 ott 2023 alle ore 16:59 tag Knife fenniclog@gmail.com ha
scritto:
This is exactly where the problem lies. Is a string with just whitespace
empty? Why would an ArrayObject with count 0 not be considered to be
empty
while an array with count 0 is? "empty" is subjective and therefore not a
reliable function to use. Especially in legacy code I find that people
use
emptywhere they should've been usingcount() === 0and have resulted
in bugs that weren't discovered until months or years later. The
variations
of$a === '',count($a) === 0,! isset($a), and$a === null
already
check all the scenarios you need, without risking funky bugs due to how
the
internal check for "falsy" values works.trust me, Ive worked on some terrible code bases that do
exactly that and have variables redefined or dynamically assigned
and you have to really check if it has been assigned a value or
not and what value.It might be forgotten by everyone because of how far PHP has come
but there is still extensive use of the @ suppressor and the
alternative to empty would beif (@$var == "" || @$var == null || @$var == [] || count(@$var) == 0){}
empty() is 1 of 3 functions i believe that does not throw an undefined
variable warning if you don't @ suppress the variable you are passing in.So if you want to get rid of empty, can we reignite the talks to finally
get rid of @
Hi there, it's a legacy function, and I don't think we can afford or
we should consider this bc break. Though I don't use this function
myself and also prefer other methods of input validation, still there
are a lot of people that use it. Renaming this to is_empty will bring
a bc break. However, the improvements to this function are worth
considering.
Ahmad
Thanks everybody for joining this discussion.
I appreciated a lot the points you raised, as they are helping me to
update and improve my rfc,
whose meaning, as I hope, would look clearer than the earlier version.Improvements must be achieved, whatever they would cost.
Ambiguities shall be resolved. I think this is the first principle in
computer science: 0 or 1 ! :-D
In any case, they are not assumed to be resort into cut-off transitions:
they may be achieved within 3, 4 or 5 versions.
Don't be scared.
I have implemented my version in my own library and it works like a charm:
you'll have exactly what you read.Alessandro Rosa
Il giorno lun 30 ott 2023 alle ore 16:59 tag Knife fenniclog@gmail.com ha
scritto:This is exactly where the problem lies. Is a string with just
whitespace
empty? Why would an ArrayObject with count 0 not be considered to be
empty
while an array with count 0 is? "empty" is subjective and therefore not
a
reliable function to use. Especially in legacy code I find that people
use
emptywhere they should've been usingcount() === 0and have
resulted
in bugs that weren't discovered until months or years later. The
variations
of$a === '',count($a) === 0,! isset($a), and$a === null
already
check all the scenarios you need, without risking funky bugs due to how
the
internal check for "falsy" values works.trust me, Ive worked on some terrible code bases that do
exactly that and have variables redefined or dynamically assigned
and you have to really check if it has been assigned a value or
not and what value.It might be forgotten by everyone because of how far PHP has come
but there is still extensive use of the @ suppressor and the
alternative to empty would beif (@$var == "" || @$var == null || @$var == [] || count(@$var) == 0){}
empty() is 1 of 3 functions i believe that does not throw an undefined
variable warning if you don't @ suppress the variable you are passing in.So if you want to get rid of empty, can we reignite the talks to finally
get rid of @
I would be voting against any function that checks for "empty". The
empty() construct we have now should almost never be used in any
reasonable code. It should be avoided at all cost. For this reason, I
see no need to introduce a new variant of the same thing. I also don't
believe there is any need to fix or change the existing construct.
Leave it as it is for use in legacy projects. Maybe in a distant
future we will be able to deprecate it or maybe we won't. While I
personally consider it a menace, I don't mind it existing in the
language.
But please do not add any similar functionality.
On Mon, Oct 30, 2023 at 1:24 PM Alessandro Rosa alessandro.a.rosa@gmail.com
wrote:
Hi,
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.Thanks,
Alessandro Rosa
WEB : http://alessandrorosa.altervista.org
LINKEDIN : https://www.linkedin.com/in/alessandro-rosa-9b7ba67b/
If anything I'd rather see empty() disappear, but I'll settle with a
warning to be cautious when using it. We don't need a replacement as you
should create your own function to validate what you consider "empty" or
not based on the given context and variable type. For me `(bool) false or
"(int) 0" isn't empty either, it's still a value of sorts.
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]
Hi Mr. Tommins,
thank you very much for all your very valuable advices.
You can read a more robust discussion about my RFC at
https://wiki.php.net/rfc/empty_function
Regards,
Alessandro Rosa
Il giorno lun 30 ott 2023 alle ore 23:54 Rowan Tommins <
rowan.collins@gmail.com> ha scritto:
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]--
To unsubscribe, visit: https://www.php.net/unsub.php
Hi Alessandro,
It would be better to add syntax highlighting to the code examples of
your RFC, it is not legal to read/understand the texts as if they were
just texts.
Marcos Marcolin
Software Engineer | PHP
www.marcosmarcolin.com.br
Hi Marcos,
thanks for feedback.
Could you be clearer about your advice and gimme an example please?
Alessandro
Il giorno mar 31 ott 2023 alle ore 11:59 Marcos Marcolin <
marcolindev@gmail.com> ha scritto:
Hi Alessandro,
It would be better to add syntax highlighting to the code examples of
your RFC, it is not legal to read/understand the texts as if they were
just texts.
Marcos Marcolin
Software Engineer | PHP
www.marcosmarcolin.com.br
On Tue, 31 Oct 2023 at 11:23, Alessandro Rosa alessandro.a.rosa@gmail.com
wrote:
Hi Marcos,
thanks for feedback.
Could you be clearer about your advice and gimme an example please?
I have edited the RFC content to add highlighting, hopefully you can now
use that to improve the RFC text.
However, I'm not very convinced at the moment that such a function is truly
useful.
Best regards,
Gina/George P. Banyard
Thank you, G.P.B. for editing and for sharing your honest viewpoint.
I saw your corrections and already fixed some flaws in the RFC text.
I raised issues that are critical on my modest viewpoint.
I see languages as an optimal mix between semantics, grammar and
performance.
The built-in empty() functions really needs to be revisited along these
directions.
Sincerely,
Alessandro Rosa
Il giorno mar 31 ott 2023 alle ore 12:34 G. P. B. george.banyard@gmail.com
ha scritto:
On Tue, 31 Oct 2023 at 11:23, Alessandro Rosa alessandro.a.rosa@gmail.com
wrote:Hi Marcos,
thanks for feedback.
Could you be clearer about your advice and gimme an example please?I have edited the RFC content to add highlighting, hopefully you can now
use that to improve the RFC text.However, I'm not very convinced at the moment that such a function is
truly useful.Best regards,
Gina/George P. Banyard
Hi Alessandro,
I would still advise to just let this empty() construct die a natural
death.
If you want to change anything, you must remember that it's basically a
syntactic sugar for @!$var
For example if(empty($var)) is just if(@!$var)
To change this function would require changing the rules for type juggling.