Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84975
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <55064508.6050206@eliw.com>
References: <CANUQDCjK7F1H5PZeV4XXvbDOsmyYtG4P1fPH3QnKBuY9EM-JdA@mail.gmail.com>
 <5504EF9D.1000707@gmail.com> <55064508.6050206@eliw.com>
Date: Mon, 16 Mar 2015 11:03:17 +0800
Message-ID: <CAEZo+gdHbAUn+Vz1vruscJSMViEvU1y=Q2P_4LTASAcqwsgH0w@mail.gmail.com>
To: Eli <eli@eliw.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC][PRE-VOTE] In Operator
From: hufeng1987@gmail.com (Netroby)

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>:
> 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   |