Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84974 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 54015 invoked from network); 16 Mar 2015 02:51:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Mar 2015 02:51:00 -0000 Authentication-Results: pb1.pair.com header.from=eli@eliw.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=eli@eliw.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain eliw.com designates 69.195.222.200 as permitted sender) X-PHP-List-Original-Sender: eli@eliw.com X-Host-Fingerprint: 69.195.222.200 mx-mia-3.servergrove.com Received: from [69.195.222.200] ([69.195.222.200:34950] helo=mx-mia-3.servergrove.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 11/2F-06614-F0546055 for ; Sun, 15 Mar 2015 21:50:58 -0500 Received: from [69.195.222.232] (helo=smtp1.servergrove.com) by mx-mia-3.servergrove.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1YXL7E-0002EC-Lp for internals@lists.php.net; Mon, 16 Mar 2015 02:50:52 +0000 Received: from [69.136.226.104] (port=50248 helo=crossbow.local) by smtp1.servergrove.com with esmtpsa (UNKNOWN:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1YXL7E-0003j9-Db; Mon, 16 Mar 2015 02:50:52 +0000 Message-ID: <55064508.6050206@eliw.com> Date: Sun, 15 Mar 2015 22:50:48 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: internals@lists.php.net References: <5504EF9D.1000707@gmail.com> In-Reply-To: <5504EF9D.1000707@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="huC7ElUW0meuuUIPM39MiW6OjiSfvx9Xx" Subject: Re: [PHP-DEV] [RFC][PRE-VOTE] In Operator From: eli@eliw.com (Eli) --huC7ElUW0meuuUIPM39MiW6OjiSfvx9Xx Content-Type: multipart/alternative; boundary="------------050406050201070900060707" This is a multi-part message in MIME format. --------------050406050201070900060707 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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. =20 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. =2E.. 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 --=20 | Eli White | http://eliw.com/ | Twitter: EliW | --------------050406050201070900060707 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/14/15 10:34 PM, Stanislav Malyshev wrote:
Hi!


I'd like to announce that I'll open the vote for t=
he 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:=C2=A0 I understand why you s= aid you don't feel it's necessary.=C2=A0 (Of course, there are millions o= f features we have that aren't necessary, *grin*)

But I'd like to know from your POV:=C2=A0 Does this harm anything?
Because from my own POV:=C2=A0 I see some great benefits of this feat= ure, and my first thoughts were 'oooh'.=C2=A0 The reasons mostly fall arou= nd cognitive dissonance.=C2=A0 Two cases in particular:<= br>
1.

I feel that this syntax being proposed, much better matches the way that we think through a problem in the first place.=C2=A0=C2=A0 You d= on't have to take a 'step back' when coding to refactor your thought process into a function.=C2=A0=C2=A0 So if I'm thinking about a problem I'm t= hinking (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.=C2=A0=C2=A0 Because in this situation my p= rocess 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?=C2=A0= 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.=C2=A0=C2=A0= 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.=C2=A0 But just that I'm very oft= en dealing with people 'new or newer to the language'.=C2=A0 Professiona= lly training them, or Unofficial Training, mentoring, helping out ... seeing people at conferences and talking with them, etc.=C2=A0=C2=A0 =

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

...

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

Thanks Stas!
Eli

--=20
|   Eli White   |   http://eliw.com/   |   Twitter: EliW   |
--------------050406050201070900060707-- --huC7ElUW0meuuUIPM39MiW6OjiSfvx9Xx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUGRQsACgkQUTBVzmoxCKImQQCfVKT1bOKEWV/Bq2dJTcp86EaG JgkAnRV/N0jeg2zMQwkLNaudS5gHrqSD =uhq3 -----END PGP SIGNATURE----- --huC7ElUW0meuuUIPM39MiW6OjiSfvx9Xx--