Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84976
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.174 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
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 12:05:31 +0900
Message-ID: <CAGa2bXZJpvuinGGR4-X6Y8V7SxhjgJN3yuTmpM4M1msnf0CPYA@mail.gmail.com>
To: Eli <eli@eliw.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113d6b72e0b09805115f21bb
Subject: Re: [PHP-DEV] [RFC][PRE-VOTE] In Operator
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a113d6b72e0b09805115f21bb
Content-Type: text/plain; charset=UTF-8

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

--001a113d6b72e0b09805115f21bb--