Re: [RFC][PRE-VOTE] In Operator

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