Re: [PHP-DEV] New RFC : empty() function
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.
Re: [PHP-DEV] New RFC : empty() function
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. ha scritto: > > On Tue, 31 Oct 2023 at 11:23, Alessandro Rosa > 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 > > > >
Re: [PHP-DEV] New RFC : empty() function
On Tue, 31 Oct 2023 at 11:23, Alessandro Rosa 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
Re: [PHP-DEV] New RFC : empty() function
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 < marcolin...@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 >
Re: [PHP-DEV] New RFC : empty() function
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
Re: [PHP-DEV] New RFC : empty() function
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.coll...@gmail.com> ha scritto:
> 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 "" 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]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Re: [PHP-DEV] New RFC : empty() function
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 "" 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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] New RFC : empty() function
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] New RFC : empty() function
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
On 10/30/23, Alessandro Rosa wrote:
> 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 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
>> > `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.
>> >
>>
>> 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 @
>>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] New RFC : empty() function
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 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
> > `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.
> >
>
> 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 @
>
Re: [PHP-DEV] New RFC : empty() function
>
> 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.
>
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 @
Re: [PHP-DEV] New RFC : empty() function
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 ha scritto: > On Mon, Oct 30, 2023 at 4:21 PM tag Knife wrote: > > > > > > > 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. >
Re: [PHP-DEV] New RFC : empty() function
On Mon, Oct 30, 2023 at 4:21 PM tag Knife wrote: > > > > 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.
Re: [PHP-DEV] New RFC : empty() function
> > 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.
Re: [PHP-DEV] New RFC : empty() function
On Mon, Oct 30, 2023 at 1:24 PM Alessandro Rosa 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.
Re: [PHP-DEV] New RFC : empty() function
Hello, I understand that the idea of the RFC is about some behaviors of empty(), e.g.: ```php $var = ''; var_dump(empty($var)); // true $var= []; 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.
Re: [PHP-DEV] New RFC : empty() function
On 30.10.2023 13:24, Alessandro Rosa 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] New RFC : empty() function
Hi, I don't understand what you are proposing and what problem you are trying to fix. The RFC is not explaining things well.
[PHP-DEV] New RFC : empty() function
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/
