RE: [PHP-DEV] [RFC] Make empty() a Variadic
Hey Dan, Making it easier to write bad (imo) code does not seem a good reason for a change. The point of this language feature isn't to promote or simplify the creation of bad code. Developers can (and will) misuse any feature to write poor code. The aim of this RFC is to enable developers to write less verbose code for what seems like a common scenario in code bases. Whilst the examples I shows may not be demonstrating the highest quality of code out there, they do show that code does exist (and in popular projects too) that could benefit from having this feature included into PHP. cheers Dan Thanks, Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Make empty() a Variadic
Hey Markus, From the RFC: This behaviour seems to be the most prevalent usage of multiple empty checks in a condition, therefore benefitting the most end users. Here I disagree. I would have assumed from the start that empty() would only return true if *all* of the entries are empty, i.e. AND things together. If we enable variable arity then it will join the group of function where no user sanely can remember if in_array/etc. take the needle/haystack first or second argument. I.e. whether it will OR or AND all arguments. My rationale for this is that empty() performs an inverse check to isset(), so I feel it should have inversed behaviour too (i.e. logically OR'ing its arguments together instead of logically AND'ing them together). To quote what Andrea wrote in the pre-RFC discussion thread: From: Andrea Faulds Date: Fri Feb 13 06:31:38 2015 So !empty($a, $b, $c) would work similarly to isset($a, $b, $c), and similarly, !isset($a, $b, $c) would work similarly to empty($a, $b, $c). This means that we keep the (rough) equivalence of `empty() == !isset()` - which is true since a variable that is not set or is null is going to be a falsy value, so both the `empty()` and `!isset()` expressions will return TRUE. Likewise for `!empty() == isset()` - if an argument does not have a falsy value, then empty() will return FALSE. isset() will return TRUE on that same value since a variable cannot be truthy and either not set or null. Now, if we changed the semantics to how you're seeing them, then we would have the following:?php$a = true;$b = 'b';// $c;var_dump(empty($a, $b, $c) === isset($a, $b, $c)); // true This behaviour seems incorrect to me, since *both* expressions will return FALSE. So how can two constructs that have inverse purposes be equal to each other on the same input? With the currently proposed behaviour, the empty() expression will return TRUE, whilst the isset() expression will return FALSE, giving the inverse result. From http://php.net/manual/en/function.isset.php : If multiple parameters are supplied then isset() will return TRUE only if all of the parameters are set. Evaluation goes from left to right and stops as soon as an unset variable is encountered. But this is an AND: ... if all ... are set: isset($a,$b) behaves like isset($a) isset($b) IMHO this absolutely violates your POLA because as I said this is also how I would assume empty() with variable arguments would work: Only return true if all are true. If we had an empty-based function that did not perform a reverse check to isset(), such as `not_empty()`, then I'd say it should behave like isset(): var_dump(not_empty($a, $b, $c) === isset($a, $b, $c)); // true But because this is not the case for empty(), I'd say it would be confusing for it to act the same way isset() does. My personal opinion is that any attempt to change this is ill-fated because people will no be able to memoize the exact usage of it because it would mean different things to different people and would just add more confusion. My aim is to make empty()'s behaviour intuitive so that users don't have to memorise its semantics. - Markus Thanks for your input Markus and I hope you can better see where I am coming from with my current RFC :) -Tom
RE: [PHP-DEV] [RFC] Make empty() a Variadic
// Sorry, having email formatting problems still. Hopefully this one will be more legible. Hey Markus, From the RFC: This behaviour seems to be the most prevalent usage of multiple empty checks in a condition, therefore benefitting the most end users. Here I disagree. I would have assumed from the start that empty() would only return true if *all* of the entries are empty, i.e. AND things together. If we enable variable arity then it will join the group of function where no user sanely can remember if in_array/etc. take the needle/haystack first or second argument. I.e. whether it will OR or AND all arguments. My rationale for this is that empty() performs an inverse check to isset(), so I feel it should have inversed behaviour too (i.e. logically OR'ing its arguments together instead of logically AND'ing them together). To quote what Andrea wrote in the pre-RFC discussion thread: From: Andrea Faulds Date: Fri Feb 13 06:31:38 2015 So !empty($a, $b, $c) would work similarly to isset($a, $b, $c), and similarly, !isset($a, $b, $c) would work similarly to empty($a, $b, $c). This means that we keep the (rough) equivalence of `empty() == !isset()` - which is true since a variable that is not set or is null is going to be a falsy value, so both the `empty()` and `!isset()` expressions will return TRUE. Likewise for `!empty() == isset()` - if an argument does not have a falsy value, then empty() will return FALSE. isset() will return TRUE on that same value since a variable cannot be truthy and either not set or null. Now, if we changed the semantics to how you're seeing them, then we would have the following:?php$a = true;$b = 'b';// $c;var_dump(empty($a, $b, $c) === isset($a, $b, $c)); // true This behaviour seems incorrect to me, since *both* expressions will return FALSE. So how can two constructs that have inverse purposes be equal to each other on the same input? With the currently proposed behaviour, the empty() expression will return TRUE, whilst the isset() expression will return FALSE, giving the inverse result. From http://php.net/manual/en/function.isset.php : If multiple parameters are supplied then isset() will return TRUE only if all of the parameters are set. Evaluation goes from left to right and stops as soon as an unset variable is encountered. But this is an AND: ... if all ... are set: isset($a,$b) behaves like isset($a) isset($b) IMHO this absolutely violates your POLA because as I said this is also how I would assume empty() with variable arguments would work: Only return true if all are true. If we had an empty-based function that did not perform a reverse check to isset(), such as `not_empty()`, then I'd say it should behave like isset(): var_dump(not_empty($a, $b, $c) === isset($a, $b, $c)); // true But because this is not the case for empty(), I'd say it would be confusing for it to act the same way isset() does. My personal opinion is that any attempt to change this is ill-fated because people will no be able to memoize the exact usage of it because it would mean different things to different people and would just add more confusion. My aim is to make empty()'s behaviour intuitive so that users don't have to memorise its semantics. - Markus Thanks for your input Markus and I hope you can better see where I am coming from with my current RFC :) -Tom
Re: [PHP-DEV] [RFC] Make empty() a Variadic
On 21 February 2015 at 07:20, Markus Fischer mar...@fischer.name wrote:
On 21.02.15 06:11, Thomas Punt wrote:
From the RFC:
Also, it will make empty() more inline with the not-too-disimillar isset(),
Here I disagree.
I would have assumed from the start that empty() would only return true
if *all* of the entries are empty, i.e. AND things together.
The problem stems from the fact that 'empty' is a falsy statement as
it returns true when something is not set. Combining two positive
results in another positive statement. Combining two negative
statements results in a positive statement.except when it doesn't.
You always have to think about what is the correct way to combine
them.
From the RFC:
In PHP, it is not uncommon to see conditionals consisting of multiple empty()
invocations. This is evident by simply browsing through some popular open
source projects
This is subjective opinion, but at least two of those code examples
are horrible. In particular the phpBB code shows the problem of using
compound 'falsy' statements:
return !(
empty($this-config['jab_enable']) ||
empty($this-config['jab_host']) ||
empty($this-config['jab_username']) ||
empty($this-config['jab_password']) ||
!@extension_loaded('xml')
);
Seriously, a double-negative at the end of a five piece statement that
combines falsy things? Making it easier to write bad (imo) code does
not seem a good reason for a change.
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Make empty() a Variadic
Hey Leigh, Hey Tom, Patch looks solid (basically the same as the isset logic with OR instead of AND). I think it's fairly sane to have this feature because it compliments isset functionality (although I dislike empty personally - consistency is nice) No RFC would be complete without a complaint about naming. empty_expressions ... I'll give you an empty expression! But overall +1 on functionality and patch. Cheers! Leigh. Thanks for the feedback :) -Tom
Re: [PHP-DEV] [RFC] Make empty() a Variadic
Hey Tom, Patch looks solid (basically the same as the isset logic with OR instead of AND). I think it's fairly sane to have this feature because it compliments isset functionality (although I dislike empty personally - consistency is nice) No RFC would be complete without a complaint about naming. empty_expressions ... I'll give you an empty expression! But overall +1 on functionality and patch. Cheers! Leigh. On 21 February 2015 at 05:11, Thomas Punt tp...@hotmail.co.uk wrote: Hello Internals! The following RFC aims to make empty() have a variable arity: https://wiki.php.net/rfc/variadic_empty. This is a simple feature that enables for a short-hand notation of checking multiple expressions for emptiness (which is a pretty common thing to do). I have avoided including the is_*() functions into this RFC because my main priority is to get this particular feature into PHP 7.0 before feature freeze. Provided I have some free time over the next week, I'll write up another RFC + patch to cover the is_*() functions. Thanks,Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Make empty() a Variadic
Hello Internals! The following RFC aims to make empty() have a variable arity: https://wiki.php.net/rfc/variadic_empty. This is a simple feature that enables for a short-hand notation of checking multiple expressions for emptiness (which is a pretty common thing to do). I have avoided including the is_*() functions into this RFC because my main priority is to get this particular feature into PHP 7.0 before feature freeze. Provided I have some free time over the next week, I'll write up another RFC + patch to cover the is_*() functions. Thanks,Tom
Re: [PHP-DEV] [RFC] Make empty() a Variadic
On 21.02.15 06:11, Thomas Punt wrote: Hello Internals! The following RFC aims to make empty() have a variable arity: https://wiki.php.net/rfc/variadic_empty. This is a simple feature that enables for a short-hand notation of checking multiple expressions for emptiness (which is a pretty common thing to do). I have avoided including the is_*() functions into this RFC because my main priority is to get this particular feature into PHP 7.0 before feature freeze. Provided I have some free time over the next week, I'll write up another RFC + patch to cover the is_*() functions. From the RFC: This behaviour seems to be the most prevalent usage of multiple empty checks in a condition, therefore benefitting the most end users. Here I disagree. I would have assumed from the start that empty() would only return true if *all* of the entries are empty, i.e. AND things together. If we enable variable arity then it will join the group of function where no user sanely can remember if in_array/etc. take the needle/haystack first or second argument. I.e. whether it will OR or AND all arguments. From the RFC: Also, it will make empty() more inline with the not-too-disimillar isset(), which is good for the Principle of Least Astonishment (mainly aimed at neophyte developers). From http://php.net/manual/en/function.isset.php : If multiple parameters are supplied then isset() will return TRUE only if all of the parameters are set. Evaluation goes from left to right and stops as soon as an unset variable is encountered. But this is an AND: ... if all ... are set: isset($a,$b) behaves like isset($a) isset($b) IMHO this absolutely violates your POLA because as I said this is also how I would assume empty() with variable arguments would work: Only return true if all are true. My personal opinion is that any attempt to change this is ill-fated because people will no be able to memoize the exact usage of it because it would mean different things to different people and would just add more confusion. -1 on the proposed change. - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
