Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83390
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.co.uk designates 157.55.1.163 as permitted sender)
Message-ID: <DUB113-W59E0378DAA53EED0174359F92B0@phx.gbl>
Content-Type: multipart/alternative;
	boundary="_57d62378-dba3-43fc-a2c3-6e49482d8bd8_"
To: Markus Fischer <markus@fischer.name>, "internals@lists.php.net"
	<internals@lists.php.net>
Date: Sat, 21 Feb 2015 14:53:54 +0000
Importance: Normal
In-Reply-To: <54E831BA.80609@fischer.name>
References:
 <DUB113-W13349F3B070957C64B0AF18F92B0@phx.gbl>,<54E831BA.80609@fischer.name>
MIME-Version: 1.0
Subject: RE: [PHP-DEV] [RFC] Make empty() a Variadic
From: tpunt@hotmail.co.uk (Thomas Punt)

--_57d62378-dba3-43fc-a2c3-6e49482d8bd8_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
Hey Markus=2C

> From the RFC:
> > This behaviour seems to be the most prevalent usage of multiple empty
> checks in a condition=2C therefore benefitting the most end users.
>=20
> Here I disagree.
>=20
> I would have assumed from the start that empty() would only return true
> if *all* of the entries are empty=2C i.e. AND things together.
>=20
> 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()=
=2C 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 quot=
e what Andrea wrote in the pre-RFC discussion thread:
> From: Andrea Faulds> Date: Fri Feb 13 06:31:38 2015>> So !empty($a=2C $b=
=2C $c) would work similarly to isset($a=2C $b=2C $c)=2C and similarly=2C !=
isset($a=2C $b=2C $c) would work similarly to empty($a=2C $b=2C $c).
This means that we keep the (rough) equivalence of `empty() =3D=3D !isset()=
` - which is true since a variable that is not set or is null is going to b=
e a falsy value=2C so both the `empty()` and `!isset()` expressions will re=
turn TRUE. Likewise for `!empty() =3D=3D isset()` - if an argument does not=
 have a falsy value=2C then empty() will return FALSE. isset() will return =
TRUE on that same value since a variable cannot be truthy and either not se=
t or null.
Now=2C if we changed the semantics to how you're seeing them=2C then we wou=
ld have the following:<?php$a =3D true=3B$b =3D 'b'=3B// $c=3Bvar_dump(empt=
y($a=2C $b=2C $c) =3D=3D=3D isset($a=2C $b=2C $c))=3B // true
This behaviour seems incorrect to me=2C since *both* expressions will retur=
n FALSE. So how can two constructs that have inverse purposes be equal to e=
ach other on the same input?
With the currently proposed behaviour=2C the empty() expression will return=
 TRUE=2C whilst the isset() expression will return FALSE=2C giving the inve=
rse 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."
>=20
> But this is an AND: "... if all ... are set":
>=20
> "isset($a=2C$b)" behaves like "isset($a) && isset($b)"
>=20
> 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 i=
sset()=2C such as `not_empty()`=2C then I'd say it should behave like isset=
():
var_dump(not_empty($a=2C $b=2C $c) =3D=3D=3D isset($a=2C $b=2C $c))=3B // t=
rue
But because this is not the case for empty()=2C I'd say it would be confusi=
ng 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.

>=20
> - Markus
>=20
Thanks for your input Markus and I hope you can better see where I am comin=
g from with my current RFC :)

-Tom=0A=
=0A=
=0A=
 		 	   		  =

--_57d62378-dba3-43fc-a2c3-6e49482d8bd8_--