# [RFC][PRE-VOTE] In Operator - Thread: https://externals.io/message/84793 - Original archive: https://news-web.php.net/php.internals/84793 - Started by Niklas Keller on 2015-03-15T00:54:12+00:00 - Messages: 17 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #84793 — Niklas Keller — 2015-03-15T00:54:12+00:00 URL: https://externals.io/message/84793#84793 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 --- ## #84794 — Antonio Carlos Ribeiro — 2015-03-15T01:48:58+00:00 URL: https://externals.io/message/84793#84794 · In reply to: #84793 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)* > 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 --- ## #84795 — Niklas Keller — 2015-03-15T02:07:16+00:00 URL: https://externals.io/message/84793#84795 · In reply to: #84794 2015-03-15 2:48 GMT+01:00 Antonio Carlos Ribeiro : > 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) > > > > > […] > 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 --- ## #84796 — Yasuo Ohgaki — 2015-03-15T02:11:10+00:00 URL: https://externals.io/message/84793#84796 · In reply to: #84793 Hi Niklas, > 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 --- ## #84798 — Stanislav Malyshev — 2015-03-15T02:34:05+00:00 URL: https://externals.io/message/84793#84798 · In reply to: #84793 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 --- ## #84810 — Niklas Keller — 2015-03-15T09:18:14+00:00 URL: https://externals.io/message/84793#84810 · In reply to: #84798 2015-03-15 3:34 GMT+01:00 Stanislav Malyshev : > Hi! > > > […] > > 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 --- ## #84827 — Dan Ackroyd — 2015-03-15T14:18:52+00:00 URL: https://externals.io/message/84793#84827 · In reply to: #84793 > 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 --- ## #84944 — Stanislav Malyshev — 2015-03-15T22:17:14+00:00 URL: https://externals.io/message/84793#84944 · In reply to: #84810 Hi! > > […] > > If they were "perfectly good", ... I think you forgot to finish your argument here. > > […] > > 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. > > > […] > > 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 --- ## #84974 — eli@eliw.com — 2015-03-16T02:50:48+00:00 URL: https://externals.io/message/84793#84974 · In reply to: #84798 > Hi! > > > […] > 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 | --- ## #84975 — Netroby — 2015-03-16T03:03:17+00:00 URL: https://externals.io/message/84793#84975 · In reply to: #84974 Does the "in" support this kind of php code ? ```php : > > > 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 | --- ## #84976 — Yasuo Ohgaki — 2015-03-16T03:05:31+00:00 URL: https://externals.io/message/84793#84976 · In reply to: #84974 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: > > 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 --- ## #84977 — Yasuo Ohgaki — 2015-03-16T03:07:36+00:00 URL: https://externals.io/message/84793#84977 · In reply to: #84975 Hi Netroby, > 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 > 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 --- ## #84988 — Stanislav Malyshev — 2015-03-16T06:21:10+00:00 URL: https://externals.io/message/84793#84988 · In reply to: #84974 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 --- ## #85051 — eli@eliw.com — 2015-03-16T13:15:53+00:00 URL: https://externals.io/message/84793#85051 · In reply to: #84976 > Hi all, > > > > […] > 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 | --- ## #85053 — eli@eliw.com — 2015-03-16T13:24:03+00:00 URL: https://externals.io/message/84793#85053 · In reply to: #84988 > > […] > 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" > > […] > 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 | --- ## #85057 — Mike Willbanks — 2015-03-16T14:12:53+00:00 URL: https://externals.io/message/84793#85057 · In reply to: #84977 > Hi Netroby, > > > > > […] > 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. --- ## #85212 — Patrick ALLAERT — 2015-03-19T10:51:21+00:00 URL: https://externals.io/message/84793#85212 · In reply to: #84793 Hey, Le dim. 15 mars 2015 à 01:54, Niklas Keller 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