Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84959
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CANUQDCgY2-rS7B9WynvEqRXMKzC-y+fgTYvfUN8gsUqNPYjnsw@mail.gmail.com>
References: <CANUQDCgY2-rS7B9WynvEqRXMKzC-y+fgTYvfUN8gsUqNPYjnsw@mail.gmail.com>
Date: Mon, 16 Mar 2015 00:16:51 +0000
Message-ID: <CADyq6s+yq1inZ6twiAjxXY_3DtQqc=nA0arW24KEXFethq2qAg@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec53d5a937f8d6505115cc52b
Subject: Re: [PHP-DEV] [RFC][VOTE] In Operator
From: ocramius@gmail.com (Marco Pivetta)

--bcaec53d5a937f8d6505115cc52b
Content-Type: text/plain; charset=UTF-8

Hi Niklas,

On 15 March 2015 at 19:31, Niklas Keller <me@kelunik.com> wrote:

> Morning,
>
> I just opened the vote for the in operator, you can find the RFC here:
> https://wiki.php.net/rfc/in_operator
> Vote will be open for two weeks, counting from today.
>
> Regards, Niklas
>


I just wanted to clarify on my "no" vote, and the reason for it is that we
have perfectly functional internal as well as userland implementations of
array/Traversable search operations.

Syntactic sugar won't really make things easier when adopting the language,
and I don't like this sort of additional cognitive load either.

In short, I stand firm on my "if you can implement it in userland, don't
implement it in the language" idea.


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

--bcaec53d5a937f8d6505115cc52b--