Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84905
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basereality.com from 209.85.160.172 cause and error)
MIME-Version: 1.0
In-Reply-To: <CANUQDCgY2-rS7B9WynvEqRXMKzC-y+fgTYvfUN8gsUqNPYjnsw@mail.gmail.com>
References: <CANUQDCgY2-rS7B9WynvEqRXMKzC-y+fgTYvfUN8gsUqNPYjnsw@mail.gmail.com>
Date: Sun, 15 Mar 2015 20:36:01 +0000
Message-ID: <CA+kxMuS3=b82h2fbCoUt=WZm+QaOjBEz3KSwUOu_R=X37M16og@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][VOTE] In Operator
From: danack@basereality.com (Dan Ackroyd)

Hi Niklas,

To reiterate and explain my no vote:

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.

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