Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84653 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 20372 invoked from network); 12 Mar 2015 19:42:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Mar 2015 19:42:20 -0000 Authentication-Results: pb1.pair.com header.from=tpunt@hotmail.co.uk; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=tpunt@hotmail.co.uk; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain hotmail.co.uk designates 157.55.1.141 as permitted sender) X-PHP-List-Original-Sender: tpunt@hotmail.co.uk X-Host-Fingerprint: 157.55.1.141 dub004-omc2s2.hotmail.com Received: from [157.55.1.141] ([157.55.1.141:49370] helo=DUB004-OMC2S2.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id DB/75-24603-A1CE1055 for ; Thu, 12 Mar 2015 14:42:19 -0500 Received: from DUB113-W95 ([157.55.1.137]) by DUB004-OMC2S2.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Thu, 12 Mar 2015 12:42:12 -0700 X-TMN: [TLtRojrCbxhSa9qWMR9GlT5TECKvPj36] X-Originating-Email: [tpunt@hotmail.co.uk] Message-ID: To: Dan Ackroyd CC: "internals@lists.php.net" Date: Thu, 12 Mar 2015 19:42:12 +0000 Importance: Normal In-Reply-To: References: ,, Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Mar 2015 19:42:12.0769 (UTC) FILETIME=[A2DD9910:01D05CFC] Subject: RE: [PHP-DEV] [VOTE] Make empty() a Variadic From: tpunt@hotmail.co.uk (Thomas Punt) Hey Dan=2C=0A= =0A= >> The falsy semantics of empty() means that inlining its behaviour to exac= tly match=0A= >> isset() isn't logical.=0A= >=0A= > The problem isn't so much that the behaviour doesn't match some other=0A= > pattern in PHP=3B the problem is that the function doesn't do what its=0A= > name says it does.=0A= >=0A= > "if any arguments passed into empty() are considered falsy=2C then true= =0A= > will be returned"=0A= >=0A= > i.e. it doesn't check whether the arguments are 'empty'=2C it's checking= =0A= > whether they are 'all set and not falsy'. Having a function do=0A= > something different to what it's name suggests will lead to it being=0A= > used incorrectly a lot of the time.=0A= =0A= Yes=2C I think this is probably the discursive area that is causing a divid= e in vote.=0A= The only compromise I can think of (though not sure on its feasibility) wou= ld be=0A= to have a flag as the last parameter that defaulted to logically AND'ing it= s args=0A= with the ability to switch the semantics to logically OR the args.=0A= =0A= > The other reason I voted no=2C is that I just don't think this adds=0A= > enough to the language to be implemented in core. For at least two of=0A= > the examples in the RFC the desired functionality could be implemented=0A= > in userland.=0A= >=0A= > The size of the PHP core codebase is already unwieldy. I think any=0A= > suggested addition needs to have a clear advantage over being=0A= > implemented in userland=0A= =0A= I could understand this POV if it caused a lot of changes=2C but the patch = is=0A= pretty simple a small. I think the potential benefits brought by this featu= re=0A= is worth its weight against 10 lines of additional code in the language gra= mmar=0A= file.=0A= =0A= > cheers=0A= > Dan=0A= =0A= Thanks for reclarifying the issues you have with this RFC.=0A= =0A= -Tom=0A= =