Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84625
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.145 as permitted sender)
Message-ID: <DUB113-W1272AADCBBD2E84A7A9EB19F9060@phx.gbl>
To: "internals@lists.php.net" <internals@lists.php.net>
Date: Thu, 12 Mar 2015 09:58:36 +0000
Importance: Normal
In-Reply-To: <DUB113-W493E3375BEB1D6C28AC8FDF91D0@phx.gbl>
References: <DUB113-W493E3375BEB1D6C28AC8FDF91D0@phx.gbl>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: RE: [PHP-DEV] [VOTE] Make empty() a Variadic
From: tpunt@hotmail.co.uk (Thomas Punt)

Hey PHP Internals=2C=0A=
=0A=
So there hasn't been much discussion on this RFC=2C and yet a lot of people=
 have=0A=
voted -1 on it. This is a little disappointing because I'm not entirely sur=
e why=0A=
people are against it - and no one seems to want to debate it either.=0A=
=0A=
From pre-RFC discussions=2C two main concerns were raised:=0A=
1. This will promote the creation of poor code.=0A=
2. The proposed semantics of empty() is wrong. It should be equivalent to l=
ogically=0A=
AND'ing empty()'s arguments together - just like with isset().=0A=
=0A=
To readdress these two points:=0A=
=0A=
1.=0A=
Any feature that reduces the amount of written code can be said to make it=
=0A=
easier to write code - regardless of whether this is good or bad code. That=
=0A=
part is up to the developer.=0A=
=0A=
Perhaps the examples in my RFC do not portray this feature in the best of=
=0A=
lights - they were simply meant to show the more extreme usages of empty()=
=0A=
in popular=2C real-world codebases. So let me provide some statistics.=0A=
=0A=
I ran the following egrep on a number of CMSs (the regular expression used =
isn't=0A=
perfect=2C but it still gives some sort of approximation):=0A=
=0A=
egrep -rio '(empty\(.*\) *(\|\| *empty\(.*\))+)|(!empty\(.*\) *(&& *!empty\=
(.*\))+)' project_dir/ | wc -l=0A=
=0A=
Results:=0A=
WordPress: 50=0A=
OpenCart: 22=0A=
phpbb: 36=0A=
Drupal: 74=0A=
SMF2.1: 266=0A=
Joomla: 23=0A=
=0A=
So the proposed short-hand notation of empty() in this RFC does have its=0A=
usages. Just as a full disclaimer though=2C framework codebases will not se=
e=0A=
this same usefulness since they don't handle business-specific validation l=
ogic=0A=
on input fields=2C web service data=2C etc (which seems like the predominan=
t usage=0A=
of multiple empty()'s in a single condition).=0A=
=0A=
=0A=
2.=0A=
The falsy semantics of empty() means that inlining its behaviour to exactly=
 match=0A=
isset() isn't logical.=0A=
=0A=
For example=2C we can roughly assert that `empty() =3D ! isset()`. This hol=
ds true=0A=
with the current semantics proposed by this RFC:=0A=
=0A=
$defined =3D 1=3B=0A=
// $undefined=3B=0A=
var_dump(empty($defined=2C $undefined) =3D=3D=3D ! isset($defined=2C $undef=
ined))=3B // bool(true)=0A=
=0A=
If empty()'s arguments were logically AND'ed together=2C then the above ass=
ertion would=0A=
not hold true.=0A=
=0A=
=0A=
So those are the two arguments I'm aware of - if anyone in the -1 camp has =
any=0A=
other reasons=2C then please do raise them!=0A=
=0A=
Thanks=2C=0A=
Tom=0A=
=0A=
> Hello PHP Internals!=0A=
>=0A=
> I'd like to put the variadic empty() RFC to vote.=0A=
>=0A=
> RFC: https://wiki.php.net/rfc/variadic_empty=0A=
>=0A=
> Voting will finish in 14 days time on March 21st.=0A=
>=0A=
> Thanks=2C=0A=
> Tom=0A=
=0A=
 		 	   		  =