Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84944
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.54 as permitted sender)
Message-ID: <550604EA.8050508@gmail.com>
Date: Sun, 15 Mar 2015 15:17:14 -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>
CC: PHP Internals <internals@lists.php.net>
References: <CANUQDCjK7F1H5PZeV4XXvbDOsmyYtG4P1fPH3QnKBuY9EM-JdA@mail.gmail.com>	<5504EF9D.1000707@gmail.com> <CANUQDCiAyprWB7A_aZ1f1SztaKP88GA=rnEE2eb8RBM2FOxO+g@mail.gmail.com>
In-Reply-To: <CANUQDCiAyprWB7A_aZ1f1SztaKP88GA=rnEE2eb8RBM2FOxO+g@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 think this operator is unnecessary - we already have perfectly good
>> function that does the same.
> 
> If they were "perfectly good", ...

I think you forgot to finish your argument here.

>> 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.
> 
> We already have a language construct here that's not a function call: isset.

I'm pretty sure you misunderstood my argument. I am not arguing against
introducing operators and language constructs in the language in
general, I am well aware that more than one exists. I am arguing this
particular operator duplicates a function and promotes wrong patterns.

> 
>> 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.
> 
> It's different for strings, yes, but where's the inconsistency?

The inconsistency is that for array, it's "has $foo as a sub-variable",
i.e. there's $x so that $bar[$x] returns "foo". For string, it's not $x
that $bar[$x] returns "foo", but $x so that substr($bar, $x,
strlen("foo")) returns "foo". Worse yet, you never know which case is it.

> A common user case would probably be checking user input against a set
> of values. As others already mentioned in the discussion there have

That's exactly what I am saying - checking against set of values by
putting them into plain array and comparing them one by one is not a
very good pattern, especially when set of values has non-negligible size.

> been security issues using non-strict in_array in the past.

in_array has strict option since... well, forever. If somebody doesn't
know about it and has security problems, why do you assume he would know
about your operator?
-- 
Stas Malyshev
smalyshev@gmail.com