[RFC][PRE-VOTE] In Operator

Antonio Carlos Ribeiro

11 years ago

Niklas,

I have to thank you for creating this RFC, I simply love it, every time I
have to use in_array() I feel PHP misses an "in" operator. I cannot vote,
but you have my spiritual support :)


Antonio Carlos Ribeiro
acr@antoniocarlosribeiro.com

(+55) 21-9-8088-2233 (celular TIM)
(+55) 21-2556-3164 (fixo residencial)

skype: antoniocarlosribeiro

_______________

*I must say I find television very educational. The minute somebody turns
it on, I go to the library and read a good book.** (*

*Devo dizer que acho televisão muito educativo. Quando alguém a liga, vou à
biblioteca e leio um bom livro.) (Groucho Marx)*


On Sat, Mar 14, 2015 at 9:54 PM, Niklas Keller <me@kelunik.com> wrote:

Niklas Keller

11 years ago

2015-03-15 2:48 GMT+01:00 Antonio Carlos Ribeiro <acr@antoniocarlosribeiro.com>:

> Niklas,
>
> I have to thank you for creating this RFC, I simply love it, every time I
> have to use in_array() I feel PHP misses an "in" operator. I cannot vote,
> but you have my spiritual support :)

Thanks for your feedback. :)

> Antonio Carlos Ribeiro
> acr@antoniocarlosribeiro.com
>
> (+55) 21-9-8088-2233 (celular TIM)
> (+55) 21-2556-3164 (fixo residencial)
>
> skype: antoniocarlosribeiro
>
> _______________
>
> I must say I find television very educational. The minute somebody turns it
> on, I go to the library and read a good book. (Devo dizer que acho televisão
> muito educativo. Quando alguém a liga, vou à biblioteca e leio um bom
> livro.)
>
> (Groucho Marx)
>
>
> On Sat, Mar 14, 2015 at 9:54 PM, Niklas Keller <me@kelunik.com> wrote:
>>
>> Morning,
>>
>> 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
>>
>> There was a small change: If the haystack is a string, integers are no
>> longer allowed as needle. This change was necessary so it's
>> consistently strict for both, array and string haystacks.
>>
>> Regards, Niklas
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>

I just adjusted the Backwards Incompatible Changes section, as class
constant and method names will no longer be affected due to the
context sensitive lexer dependency.

Regards, Niklas

Yasuo Ohgaki

11 years ago

Hi Niklas,

On Sun, Mar 15, 2015 at 9:54 AM, Niklas Keller <me@kelunik.com> wrote:

> 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
>
> There was a small change: If the haystack is a string, integers are no
> longer allowed as needle. This change was necessary so it's
> consistently strict for both, array and string haystacks.
>

I would vote "no".

1. PHP is weakly typed (well at least it is currently)
2. "in" operator does not work well enough for weakly typed types
3. We have discussions how PHP should be type aware currently

These are reasons why I would vote "no" for this now.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Stas Malyshev

11 years ago

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

Niklas Keller

11 years ago

2015-03-15 3:34 GMT+01:00 Stanislav Malyshev <smalyshev@gmail.com>:

> 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.

If they were "perfectly good", ...

> 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.

We already have a language construct here that's not a function call: isset.

> 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?

A common user case would probably be checking user input against a set
of values. As others already mentioned in the discussion there have
been security issues using non-strict in_array in the past.

> --
> Stas Malyshev
> smalyshev@gmail.com

Regards, Niklas

Stas Malyshev

11 years ago

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

Eli

11 years ago

On 3/14/15 10:34 PM, Stanislav Malyshev wrote:

> 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.

Hello Stas ... a quick question for you:  I understand why you said you
don't feel it's necessary.  (Of course, there are millions of features
we have that aren't necessary, *grin*)

But I'd like to know from your POV:  Does this harm anything?

Because from my own POV:  I see some great benefits of this feature, and
my first thoughts were 'oooh'.  The reasons mostly fall around cognitive
dissonance.  Two cases in particular:

1.

I feel that this syntax being proposed, much better matches the way that
we think through a problem in the first place.   You don't have to take
a 'step back' when coding to refactor your thought process into a
function.   So if I'm thinking about a problem I'm thinking (and typing
as I go:)

If we have a zebra in our zoo ... then do X

I can now with this syntax, write code that directly matches the
cognitive process:

if ($zebra in $zoo) {}

Currently, I can speak for myself, I almost always find myself doing a
'backup' step in coding.   Because in this situation my process becomes:

if ($zebra ... Oh wait, can't do that, need to use in_array

if (in_array( ... Oh wait, what's the order of parameters again?  dang
it, hit php.net or find a recent use.

if (in_array($zebra,$zoo)) {} ... *shew*

In the end, yes, you can argue that this is a small thing.   But I
believe that the simpler cognitive path that one follows with this new
syntax will bring some great benefit to coders.

2.

Well it's really the same situation.  But just that I'm very often
dealing with people 'new or newer to the language'.  Professionally
training them, or Unofficial Training, mentoring, helping out ... seeing
people at conferences and talking with them, etc.

And the newer people to the language often get tripped up on exactly
these kinds of things.  Lowering that cognitive barrier to translating
one's thought, to code.  I feel is going to be a benefit here.

...

So back to my original question.  I respect your opinion, so I'd like to
understand more.  Is this just truly a case of "Eh, we have a function
already, this isn't necessary"?   Or is there some actual harm you see
caused by it?

Thanks Stas!
Eli

--
|   Eli White   |   http://eliw.com/   |   Twitter: EliW   |

netroby

11 years ago

Does the "in" support this kind of php code ?

```php
<?php
$arr = ['a', 'b', 'c'];
for ($v in $arr) {
echo $v;
}


```

I know javascript has this kind of support

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...in

Appreciate your time.
----------------------------
Netroby


2015-03-16 10:50 GMT+08:00 Eli <eli@eliw.com>:

Yasuo Ohgaki

11 years ago

Hi Netroby,

On Mon, Mar 16, 2015 at 12:03 PM, Netroby <hufeng1987@gmail.com> wrote:

> Does the "in" support this kind of php code ?
>
> ```php
> <?php
> $arr = ['a', 'b', 'c'];
> for ($v in $arr) {
>     echo $v;
> }
>
>
> ```
>
> I know javascript has this kind of support
>
>
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...in
>

No. We have foreach for this.
Shells support this syntax, too.
It may be confusing for some users. Good point.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Mike Willbanks

11 years ago

On Sun, Mar 15, 2015 at 10:07 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi Netroby,
>
> On Mon, Mar 16, 2015 at 12:03 PM, Netroby <hufeng1987@gmail.com> wrote:
>
> > Does the "in" support this kind of php code ?
> >
> > ```php
> > <?php
> > $arr = ['a', 'b', 'c'];
> > for ($v in $arr) {
> >     echo $v;
> > }
> >
> >
> > ```
> >
> > I know javascript has this kind of support
> >
> >
> >
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...in
> >
>
> No. We have foreach for this.
> Shells support this syntax, too.
> It may be confusing for some users. Good point.
>

I had made this point earlier; not having it was not in particular a hurdle
for me but I did believe that if we added the in clause we could also
follow that type of for loop.

Yasuo Ohgaki

11 years ago

Hi all,

On Mon, Mar 16, 2015 at 11:50 AM, Eli <eli@eliw.com> wrote:

> On 3/14/15 10:34 PM, Stanislav Malyshev wrote:
>
> 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.
>
>
> Hello Stas ... a quick question for you:  I understand why you said you
> don't feel it's necessary.  (Of course, there are millions of features we
> have that aren't necessary, *grin*)
>
> But I'd like to know from your POV:  Does this harm anything?
>
> Because from my own POV:  I see some great benefits of this feature, and
> my first thoughts were 'oooh'.  The reasons mostly fall around cognitive
> dissonance.  Two cases in particular:
>
> 1.
>
> I feel that this syntax being proposed, much better matches the way that
> we think through a problem in the first place.   You don't have to take a
> 'step back' when coding to refactor your thought process into a function.
> So if I'm thinking about a problem I'm thinking (and typing as I go:)
>
> If we have a zebra in our zoo ... then do X
>
> I can now with this syntax, write code that directly matches the cognitive
> process:
>
> if ($zebra in $zoo) {}
>
> Currently, I can speak for myself, I almost always find myself doing a
> 'backup' step in coding.   Because in this situation my process becomes:
>
> if ($zebra ... Oh wait, can't do that, need to use in_array
>
> if (in_array( ... Oh wait, what's the order of parameters again?  dang it,
> hit php.net or find a recent use.
>
> if (in_array($zebra,$zoo)) {} ... *shew*
>
> In the end, yes, you can argue that this is a small thing.   But I believe
> that the simpler cognitive path that one follows with this new syntax will
> bring some great benefit to coders.
>

This is one of the issue what I'm trying to fix by this RFC.
https://wiki.php.net/rfc/consistent_function_names
This would be better fix for this issue.
Note: I added parameter issue handling to the RFC.

>
> 2.
>
> Well it's really the same situation.  But just that I'm very often dealing
> with people 'new or newer to the language'.  Professionally training them,
> or Unofficial Training, mentoring, helping out ... seeing people at
> conferences and talking with them, etc.
>
> And the newer people to the language often get tripped up on exactly these
> kinds of things.  Lowering that cognitive barrier to translating one's
> thought, to code.  I feel is going to be a benefit here.
>
> ...
>
> So back to my original question.  I respect your opinion, so I'd like to
> understand more.  Is this just truly a case of "Eh, we have a function
> already, this isn't necessary"?   Or is there some actual harm you see
> caused by it?

Please support the RFC.
Any help/support/improvement/suggestion is appreciated.

As I wrote previously, I think it's not a right time adding this operator
now at least.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Eli

11 years ago

On 3/15/15 11:05 PM, Yasuo Ohgaki wrote:

> Hi all,
>
> On Mon, Mar 16, 2015 at 11:50 AM, Eli <eli@eliw.com> wrote:
>> Currently, I can speak for myself, I almost always find myself doing a
>> 'backup' step in coding.   Because in this situation my process becomes:
>>
>> if ($zebra ... Oh wait, can't do that, need to use in_array
>>
>> if (in_array( ... Oh wait, what's the order of parameters again?  dang it,
>> hit php.net or find a recent use.
>>
>> if (in_array($zebra,$zoo)) {} ... *shew*
>>
>> In the end, yes, you can argue that this is a small thing.   But I believe
>> that the simpler cognitive path that one follows with this new syntax will
>> bring some great benefit to coders.
> This is one of the issue what I'm trying to fix by this RFC.
> https://wiki.php.net/rfc/consistent_function_names
> This would be better fix for this issue.
> Note: I added parameter issue handling to the RFC.

However your proposal here (it's own merits aside), doesn't actually
address what I mentioned.  Since it still requires the use of a
'function first' phraseology instead of a more natural language one.

If anything, it actually might hurt this one specific case.  Because at
least now, the function has a logical process to it, if you think about
it.  IE:  in_array(what, array).     Whereas switched as your proposal
allows for:   array_in(what, array).   Means the function name is kinda
backwards comparatively.

Also, it reads as if it's something else.  I'd expect by natural
language, that array_in ... would look for an array in something.   Not
the other way around.

Eli

--
|   Eli White   |   http://eliw.com/   |   Twitter: EliW   |

Stas Malyshev

11 years ago

Hi!

> But I'd like to know from your POV:  Does this harm anything?

Depends on what you see as "harm". Complicating the language is kind of
harm. Introducing stuff that promotes patterns that are not always best,
and that do a bit too much, and look too much like something in
different languages that does something close, but not exactly that - is
kind of harm. Both kinds are very small, more inconvenience than a
serious problem, and can be easily compensated for by benefits of the
feature, but given we already have all the benefits, I don't see much
point.

> I can now with this syntax, write code that directly matches the
> cognitive process:
>
> if ($zebra in $zoo) {}

Two things here:

1. If you're looking whether your zoo has a zebra, and you're doing it
by inspecting every inch of your zoo and checking if it doesn't contain
a zebra by any chance, you're running your zoo wrong. I hope this
metaphor is clear :)

2. We don't talk to computers in natural language. For many reasons. So
part of the cognitive process of any programmer is translating his
thoughts into patterns that particular software (we rarely talk to
hardware directly anymore) understands. From that POV, it doesn't matter
too much how exactly bytes that you use to represent it are arranged, as
long as they are not unnecessarily unwieldy. That, of course, is a
matter of opinion, and my opinion is in_array is fine in that regard.

> And the newer people to the language often get tripped up on exactly
> these kinds of things.  Lowering that cognitive barrier to translating
> one's thought, to code.  I feel is going to be a benefit here.

Frankly, I don't see how that would help. Because with this operator,
you'd have to tell them:

1. It's the same as in_array function, it goes through array and checks
if the element is there.
2. But not exactly - in_array can do non-strict lookup, this one can't.
3. Oh, but instead it also works on strings.
4. Where it is like strstr except it doesn't tell you *where* the
substring is.
5. And if you want to use it like Python's "in" you shouldn't because
Python's works on keys while ours works on values.
6. And unlike many other languages you can't use it in a loop either.
7. And if you want to write an *efficient* lookup you shouldn't use this
operator at all.

I don't think it is a cognitive simplification.

--
Stas Malyshev
smalyshev@gmail.com

Eli

11 years ago

On 3/16/15 2:21 AM, Stanislav Malyshev wrote:

> > if ($zebra in $zoo) {}
> Two things here:
>
> 1. If you're looking whether your zoo has a zebra, and you're doing it
> by inspecting every inch of your zoo and checking if it doesn't contain
> a zebra by any chance, you're running your zoo wrong. I hope this
> metaphor is clear :)

Heh heh.  True.   However the flip side is that this ends up being a
rather common practice (for good or bad).  Stuff like "Is this state in
my array of all states" or "Is this country in my array of all
countries" ends up happening a lot.

I like (personally) having this simplified syntactic sugar on this.

> 2. We don't talk to computers in natural language. For many reasons. So
> part of the cognitive process of any programmer is translating his
> thoughts into patterns that particular software (we rarely talk to
> hardware directly anymore) understands. From that POV, it doesn't matter
> too much how exactly bytes that you use to represent it are arranged, as
> long as they are not unnecessarily unwieldy. That, of course, is a
> matter of opinion, and my opinion is in_array is fine in that regard.

Totally understood.  Though my argument wasn't about bytes.  But just
'simplified brain to code'.  Since one could start arguing that we start
coding in whitespace instead :)  (ok ok, that was a joke).

But yeah.  I get your POV on that.  My own brain just looks at the in
syntax and goes:  "oooh, that's what I wish it had been from the beginning"

>> And the newer people to the language often get tripped up on exactly
>> these kinds of things.  Lowering that cognitive barrier to translating
>> one's thought, to code.  I feel is going to be a benefit here.
> Frankly, I don't see how that would help. Because with this operator,
> you'd have to tell them:
>
> 1. It's the same as in_array function, it goes through array and checks
> if the element is there.
> 2. But not exactly - in_array can do non-strict lookup, this one can't.
> 3. Oh, but instead it also works on strings.
> 4. Where it is like strstr except it doesn't tell you *where* the
> substring is.
> 5. And if you want to use it like Python's "in" you shouldn't because
> Python's works on keys while ours works on values.
> 6. And unlike many other languages you can't use it in a loop either.
> 7. And if you want to write an *efficient* lookup you shouldn't use this
> operator at all.
>
> I don't think it is a cognitive simplification.

Yeah - those are good points.   Though I'd see this from the POV of
step-by-step knowledge transfer.   You wouldn't teach "look at all these
complications".

You'd be able to give the '1st day lesson' on "How to see if something
is in an array" ... and "How to see if a string is in another string".
And showing them this simpler cognitive version.   But then you start
going deeper on 'advanced stuff' later :)  (and yes, in_array becomes
'advanced stuff' at that point.

It's too bad that there isn't a way to do an operator like this, in such
a way that it's more efficient and/or allows for non-strict like in_array.

Thanks for the input Stas ... I'll keep mulling this over and seeing
what others say here as well.

Eli

--
|   Eli White   |   http://eliw.com/   |   Twitter: EliW   |

Dan Ackroyd

11 years ago

On 15 March 2015 at 00:54, Niklas Keller <me@kelunik.com> wrote:

> Morning,
>
> 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

We've discussed this elsewhere and the RFC is still lacking one thing
- any justification of  why this deserves being a new piece of syntax,
rather than just being a function implemented either internally, or
even better in userland PHP.

I think that adding new syntax for something that could just be a
function is not a good idea at the best of times, but when it's such
generic keyword that could be far more useful in other places (e.g.
Linq style queries) it really needs to have a strong justification.

The equation is not just "will PHP be better with this" instead it's
"will PHP so much better that it justifies the known cost of adding
syntax to the language, as well as the unknown cost of blocking future
use of the 'in' keyword".

I'm sorry, but I just can't see that the value in adding this comes
anywhere close to justifying it's addition.

cheers
Dan

Patrick ALLAERT

11 years ago

Hey,

Le dim. 15 mars 2015 à 01:54, Niklas Keller <me@kelunik.com> a écrit :

> Morning,
>
> 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
>
> There was a small change: If the haystack is a string, integers are no
> longer allowed as needle. This change was necessary so it's
> consistently strict for both, array and string haystacks.
>
> Regards, Niklas
>

If there is one thing that can be improved in a related area: create a true
"Set" datatype.

You just don't imagine how often I encountered bottlenecks in PHP
application where in_array() was used (thousands times per request over not
so small arrays).

Sometimes it can be improved by storing the value in the key part (using an
array to emulate a hash thanks to the internal implementation of arrays),
using SplObjectStorage in case of objects or even a bloom filter
implementation [1]. Visit [2] for some inspirations.

As you see , there is room for improvement to make things easier, but that
wouldn't be by simply be achieved by adding an "in" keyword.

Everytime I see an in_array(), I also cry, but not because of the syntax,
rather because I know how it operates (think: "full table scan" if you were
doing a SELECT query without proper indexes). This simply cannot be
improved in a proper way without a true "Set" implementation.

[1] http://pecl.php.net/package/bloomy
[2]
http://technosophos.com/2009/05/29/set-objects-php-arrays-vs-splobjectstorage.html

Cheers,
Patrick