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
