Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84827
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basereality.com from 209.85.213.47 cause and error)
MIME-Version: 1.0
In-Reply-To: <CANUQDCjK7F1H5PZeV4XXvbDOsmyYtG4P1fPH3QnKBuY9EM-JdA@mail.gmail.com>
References: <CANUQDCjK7F1H5PZeV4XXvbDOsmyYtG4P1fPH3QnKBuY9EM-JdA@mail.gmail.com>
Date: Sun, 15 Mar 2015 14:18:52 +0000
Message-ID: <CA+kxMuS0F98zLxhU0CjPLf0w3J6gkUf91GTdOeiYqzeeB6yE+A@mail.gmail.com>
To: Niklas Keller <me@kelunik.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: danack@basereality.com (Dan Ackroyd)

On 15 March 2015 at 00:54, Niklas Keller <me@kelunik.com> wrote:
> Morning,
>
> 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

We've discussed this elsewhere and the RFC is still lacking one thing
- any justification of  why this deserves being a new piece of syntax,
rather than just being a function implemented either internally, or
even better in userland PHP.

I think that adding new syntax for something that could just be a
function is not a good idea at the best of times, but when it's such
generic keyword that could be far more useful in other places (e.g.
Linq style queries) it really needs to have a strong justification.

The equation is not just "will PHP be better with this" instead it's
"will PHP so much better that it justifies the known cost of adding
syntax to the language, as well as the unknown cost of blocking future
use of the 'in' keyword".

I'm sorry, but I just can't see that the value in adding this comes
anywhere close to justifying it's addition.

cheers
Dan