Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84988
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.51 as permitted sender)
Message-ID: <55067656.9080209@gmail.com>
Date: Sun, 15 Mar 2015 23:21:10 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Eli <eli@eliw.com>, internals@lists.php.net
References: <CANUQDCjK7F1H5PZeV4XXvbDOsmyYtG4P1fPH3QnKBuY9EM-JdA@mail.gmail.com> <5504EF9D.1000707@gmail.com> <55064508.6050206@eliw.com>
In-Reply-To: <55064508.6050206@eliw.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][PRE-VOTE] In Operator
From: smalyshev@gmail.com (Stanislav Malyshev)

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