Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83325
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1424447709.16516.2.camel@kuechenschabe>
References: <CANUQDCiPP9=_=ZDX7prvCNdXvxZRs3Awq-FaLDDE5K-U3hXZRQ@mail.gmail.com>
	<1424447709.16516.2.camel@kuechenschabe>
Date: Fri, 20 Feb 2015 16:56:12 +0000
Message-ID: <CALwr1GnFLJz2RAGUfCtdB2+opZE7wPWAHe4mvZqTb-RQBE0Wog@mail.gmail.com>
To: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>
Cc: Niklas Keller <me@kelunik.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC][Discussion] In Operator
From: padraic.brady@gmail.com (=?UTF-8?Q?P=C3=A1draic_Brady?=)

On 20 February 2015 at 15:55, Johannes Schl=C3=BCter <johannes@schlueters.d=
e> wrote:
> On Fri, 2015-02-20 at 13:54 +0100, Niklas Keller wrote:
>> Hi internals,
>>
>> "In Operator" is now in discussion phase.
>>
>> > This RFC adds a new in operator which simplifies contains checks for s=
trings and arrays.
>> > Currently, we have to usein_array($needle, $haystack, true) or strpos(=
$haystack, $needle) !=3D=3D false.
>> > These functions have a inconsistent parameter order, so it's hard to r=
emember which is the right one
>> > for each. The in operator makes these checks way more readable. Additi=
onally, it also works for Traversable.
>>
>> https://wiki.php.net/rfc/in_operator
>
> | It uses strict comparison (=3D=3D=3D) for array values / instances of
> | Traversable
>
> This might be nice but is inconsistent with other parts of the language
> like switch statements. I think inconsistency is worse than this
> inconvenience.

I would be in favour of strict comparison. Being consistent with
in_array() sounds great, but the loose comparison makes it difficult
to use in certain use cases. A common usage would be a contains/in
validator, for example, where loose comparisons can pass unwanted
values depending on how it's written. I'm not fumbling in the dark, it
has created a security issue in at least two frameworks.

Since it's a new operator in isolation, tightening such rules would be welc=
ome.

Paddy

--
P=C3=A1draic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com