Re: [RFC][Discussion] In Operator
| From: | Pádraic Brady | Date: | Fri, 20 Feb 2015 16:56:12 +0000 |
| Subject: | Re: [RFC][Discussion] In Operator | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-83325@lists.php.net to get a copy of this message | ||
On 20 February 2015 at 15:55, Johannes Schlüter <johannes@schlueters.de> 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 strings and
>> > arrays.
>> > Currently, we have to usein_array($needle, $haystack, true) or strpos($haystack,
>> > $needle) !== false.
>> > These functions have a inconsistent parameter order, so it's hard to remember
>> > which is the right one
>> > for each. The in operator makes these checks way more readable. Additionally, it also
>> > works for Traversable.
>>
>> https://wiki.php.net/rfc/in_operator
>
> | It uses strict comparison (===) 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 welcome.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com