Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84798
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.49 as permitted sender)
Message-ID: <5504EF9D.1000707@gmail.com>
Date: Sat, 14 Mar 2015 19:34:05 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Niklas Keller <me@kelunik.com>, 
 PHP Internals <internals@lists.php.net>
References: <CANUQDCjK7F1H5PZeV4XXvbDOsmyYtG4P1fPH3QnKBuY9EM-JdA@mail.gmail.com>
In-Reply-To: <CANUQDCjK7F1H5PZeV4XXvbDOsmyYtG4P1fPH3QnKBuY9EM-JdA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][PRE-VOTE] In Operator
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> I'd like to announce that I'll open the vote for the in operator later that day.
> You can find the RFC here: https://wiki.php.net/rfc/in_operator

I think this operator is unnecessary - we already have perfectly good
function that does the same. Also, since it checks the values and not
the keys, it would be useless for the same use case one would most
frequently use "in" in Python and such - for checking if something is in
a set of values. Since efficient implementation of the set in PHP would
have the value being sought as key, "in" would be useless, unless much
slower iterative implementation is chosen.

Also, because it includes different (and inconsistent) implementation
for strings, if you have ("foo" in $bar === true) , you don't know if
$bar is an array that includes string "foo" or a string that has "foo"
as a substring. I don't think it's good that operator would mix these
two cases.
-- 
Stas Malyshev
smalyshev@gmail.com