// 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
