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
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
