RE: [PHP-DEV] [VOTE] Make empty() a Variadic
Hey Internals, I'd like to put the variadic empty() RFC to vote. RFC: https://wiki.php.net/rfc/variadic_empty Voting will finish in 14 days time on March 21st. Voting has now ended with a 26:26 yes/no split. This means the RFC has has been declined (namely surrounding the ambiguity of what semantics empty() should have). Thanks to all who participated in the discussions and voting of this RFC! -Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Make empty() a Variadic
Le 07/03/2015 12:56, Thomas Punt a écrit : I'd like to put the variadic empty() RFC to vote. RFC: https://wiki.php.net/rfc/variadic_empty Hi, Discussing this RFC with other people at AFUP, we ended up on the -1 side (by a thin margin). The main reason given against this proposal was that it would not be clear (when writing/reading code) whether it would test for all empty / and or at least one empty / or -- like you explained in one of your mails. And it appears this is, at least for us, more of a problem than writing several empty() in a row. In any case, thanks for your work! -- Pascal MARTIN, AFUP - French UG http://php-internals.afup.org/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Make empty() a Variadic
Am 13.03.2015 um 09:57 schrieb Matteo Beccati: On 13/03/2015 07:46, Crypto Compress wrote: how about two separate methods all_empty() and non[e]_empty()? How about empty() and full() ? Ok, that was a bad attempt as a joke, but please no ;) Hello Matteo, don't get your point. Are you against my naming suggestions or the possibility to check many vars on emptiness? There are these two groups with contrary expectations. What is the downside to give both a proper solution? Thanks! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Make empty() a Variadic
On 14/03/2015 07:32, Crypto Compress wrote: Am 13.03.2015 um 09:57 schrieb Matteo Beccati: On 13/03/2015 07:46, Crypto Compress wrote: how about two separate methods all_empty() and non[e]_empty()? How about empty() and full() ? Ok, that was a bad attempt as a joke, but please no ;) Hello Matteo, don't get your point. Are you against my naming suggestions or the possibility to check many vars on emptiness? There are these two groups with contrary expectations. What is the downside to give both a proper solution? The proper solution you suggest adds two more functions and I think we plenty already. We can't make empty variadic because it's ambiguous? Fine, I think I can live with it. Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Make empty() a Variadic
how about two separate methods all_empty() and non[e]_empty()? How about empty() and full() ? Ok, that was a bad attempt as a joke, but please no ;) don't get your point. Are you against my naming suggestions or the possibility to check many vars on emptiness? There are these two groups with contrary expectations. What is the downside to give both a proper solution? The proper solution you suggest adds two more functions and I think we plenty already. For current problem area there are exactly zero functions. We can't make empty variadic because it's ambiguous? Fine, I think I can live with it. Somewhat masochistic approach considering we can unambiguous get rid of code bloat. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Make empty() a Variadic
Am 12.03.2015 um 20:42 schrieb Thomas Punt: The only compromise I can think of (though not sure on its feasibility) would be to have a flag as the last parameter that defaulted to logically AND'ing its args with the ability to switch the semantics to logically OR the args. Hello Thomas, how about two separate methods all_empty() and non[e]_empty()? Thank you! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Make empty() a Variadic
On 13/03/2015 07:46, Crypto Compress wrote: how about two separate methods all_empty() and non[e]_empty()? How about empty() and full() ? Ok, that was a bad attempt as a joke, but please no ;) Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Make empty() a Variadic
Hey PHP Internals, So there hasn't been much discussion on this RFC, and yet a lot of people have voted -1 on it. This is a little disappointing because I'm not entirely sure why people are against it - and no one seems to want to debate it either. From pre-RFC discussions, two main concerns were raised: 1. This will promote the creation of poor code. 2. The proposed semantics of empty() is wrong. It should be equivalent to logically AND'ing empty()'s arguments together - just like with isset(). To readdress these two points: 1. Any feature that reduces the amount of written code can be said to make it easier to write code - regardless of whether this is good or bad code. That part is up to the developer. Perhaps the examples in my RFC do not portray this feature in the best of lights - they were simply meant to show the more extreme usages of empty() in popular, real-world codebases. So let me provide some statistics. I ran the following egrep on a number of CMSs (the regular expression used isn't perfect, but it still gives some sort of approximation): egrep -rio '(empty\(.*\) *(\|\| *empty\(.*\))+)|(!empty\(.*\) *( *!empty\(.*\))+)' project_dir/ | wc -l Results: WordPress: 50 OpenCart: 22 phpbb: 36 Drupal: 74 SMF2.1: 266 Joomla: 23 So the proposed short-hand notation of empty() in this RFC does have its usages. Just as a full disclaimer though, framework codebases will not see this same usefulness since they don't handle business-specific validation logic on input fields, web service data, etc (which seems like the predominant usage of multiple empty()'s in a single condition). 2. The falsy semantics of empty() means that inlining its behaviour to exactly match isset() isn't logical. For example, we can roughly assert that `empty() = ! isset()`. This holds true with the current semantics proposed by this RFC: $defined = 1; // $undefined; var_dump(empty($defined, $undefined) === ! isset($defined, $undefined)); // bool(true) If empty()'s arguments were logically AND'ed together, then the above assertion would not hold true. So those are the two arguments I'm aware of - if anyone in the -1 camp has any other reasons, then please do raise them! Thanks, Tom Hello PHP Internals! I'd like to put the variadic empty() RFC to vote. RFC: https://wiki.php.net/rfc/variadic_empty Voting will finish in 14 days time on March 21st. Thanks, Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Make empty() a Variadic
On Thu, 12 Mar 2015, Thomas Punt wrote: Hey PHP Internals, So there hasn't been much discussion on this RFC, and yet a lot of people have voted -1 on it. This is a little disappointing because I'm not entirely sure why people are against it - and no one seems to want to debate it either. IMO, because it's not obvious whether it is *all* empty, or *atleast one* empty. The same argument we had before, when we expanded isset() to be variadic. We had the same discussion then, resulting on keeping empty() as it is. One discussion 11 years ago: http://marc.info/?l=php-internalsm=109836951711930 I can't find the discussion prior to that though. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Make empty() a Variadic
Hey Dan, The falsy semantics of empty() means that inlining its behaviour to exactly match isset() isn't logical. The problem isn't so much that the behaviour doesn't match some other pattern in PHP; the problem is that the function doesn't do what its name says it does. if any arguments passed into empty() are considered falsy, then true will be returned i.e. it doesn't check whether the arguments are 'empty', it's checking whether they are 'all set and not falsy'. Having a function do something different to what it's name suggests will lead to it being used incorrectly a lot of the time. Yes, I think this is probably the discursive area that is causing a divide in vote. The only compromise I can think of (though not sure on its feasibility) would be to have a flag as the last parameter that defaulted to logically AND'ing its args with the ability to switch the semantics to logically OR the args. The other reason I voted no, is that I just don't think this adds enough to the language to be implemented in core. For at least two of the examples in the RFC the desired functionality could be implemented in userland. The size of the PHP core codebase is already unwieldy. I think any suggested addition needs to have a clear advantage over being implemented in userland I could understand this POV if it caused a lot of changes, but the patch is pretty simple a small. I think the potential benefits brought by this feature is worth its weight against 10 lines of additional code in the language grammar file. cheers Dan Thanks for reclarifying the issues you have with this RFC. -Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE] Make empty() a Variadic
Hey Derick, IMO, because it's not obvious whether it is *all* empty, or *atleast one* empty. The same argument we had before, when we expanded isset() to be variadic. We had the same discussion then, resulting on keeping empty() as it is. One discussion 11 years ago: http://marc.info/?l=php-internalsm=109836951711930 I can't find the discussion prior to that though. cheers, Derick Thanks for the link. I wasn't aware this had come up in the past. -Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Make empty() a Variadic
On 12 March 2015 at 09:58, Thomas Punt tp...@hotmail.co.uk wrote: Hey PHP Internals, I'm not entirely sure why people are against it - and no one seems to want to debate it either. I think these were covered in the discussion phase, but I will reiterate the reasons I voted against it for clarity. The falsy semantics of empty() means that inlining its behaviour to exactly match isset() isn't logical. The problem isn't so much that the behaviour doesn't match some other pattern in PHP; the problem is that the function doesn't do what its name says it does. if any arguments passed into empty() are considered falsy, then true will be returned i.e. it doesn't check whether the arguments are 'empty', it's checking whether they are 'all set and not falsy'. Having a function do something different to what it's name suggests will lead to it being used incorrectly a lot of the time. The other reason I voted no, is that I just don't think this adds enough to the language to be implemented in core. For at least two of the examples in the RFC the desired functionality could be implemented in userland. The size of the PHP core codebase is already unwieldy. I think any suggested addition needs to have a clear advantage over being implemented in userland cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
