[RFC][PRE-VOTE] In Operator

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

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

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

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:

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.

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 |

Hi all,

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:

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.

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

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