Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81046
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.175 as permitted sender)
Message-ID: <54C26153.9090701@gmail.com>
Date: Fri, 23 Jan 2015 14:57:23 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CANUQDCgq5hPEk=dMg8enSLrxAdmLqHRJoKXB0rkhNff+KbaUag@mail.gmail.com> <CAGa2bXYvcS2Z2q+K9e91DBLJEiXMw03Q9MSRP7HgjZtnRJHvAA@mail.gmail.com>
In-Reply-To: <CAGa2bXYvcS2Z2q+K9e91DBLJEiXMw03Q9MSRP7HgjZtnRJHvAA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] in Operator
From: rowan.collins@gmail.com (Rowan Collins)

Yasuo Ohgaki wrote on 23/01/2015 03:01:
> Hi Niklas,
>
> On Mon, Jan 19, 2015 at 9:42 AM, Niklas Keller<me@kelunik.com>  wrote:
>
>> >I'd like to propose a new feature to PHP: The in Operator
>> >Bob mentioned a few weeks ago he wants such an operator in PHP and today I
>> >stumbled over
>> >
>> >http://nikic.github.io/2012/07/27/How-to-add-new-syntactic-features-to-PHP.html
>> >again,
>> >which uses the in operator as a sample.
>> >
>> >Use cases:
>> >
>> >$obj = new StdClass;
>> >$obj->prop = "value";
>> >$languages = ["PHP", "C", "Java"];
>> >var_dump("PHP" in $languages); // true
>> >var_dump("Python" in $languages); // false
>> >var_dump(0 in $languages); // false
>> >var_dump("0x0" in ["0e3"]); // false
>> >var_dump("prop" in $obj); // true
>> >var_dump("foo" in $obj); // false
>> >var_dump("Hello" in "Hello World!"); // true
>> >
>> >For strings, it would replace `strpos("Hello World!", "Hello") !== false)`,
>> >for arrays it would replace `in_array($needle, $haystack, true)`
>> >and for objects it would be a replacement of property_exists($class,
>> >$property)`.
>> >
>> >This change would mainly be syntax sugar, but I think it's worth because:
>> >  * `"0x0" in ["0e3"]` would return false while `in_array("0x0", ["0e3"])`
>> >returns true, that's probably an edge case, but there may be a lot of
>> >people that don't use the `$strict` parameter, seehttp://3v4l.org/0K7E5
>> >  * It would solve the issue that it's hard to remember the order of the
>> >arguments for in_array and strpos, just had to look it up again.
>> >
>> >Bob would volunteer to implement that feature.
>> >
> I would like to reserve 'in' and 'out' for Design by Contract (DbC).
> http://en.wikipedia.org/wiki/Design_by_contract
>
> D language has in and out like
>
> function foo() {
> in {
>     // precondition
> }
> out {
>    // postcondition
> }
> {
>    // function body
> }

Would this conflict? It seems to me that this syntax could only ever 
exist in a declaration (function signature) context, and the proposed in 
operator could only ever exist in a procedural code (function body) 
context, which are surely completely separate sections of the parser.

If anything, wanting the keyword for another purpose might strengthen 
its case, because each feature isn't reserving a new word. It's not the 
first keyword to have distinct meanings by context - "use" means very 
different things for namespaces, traits, and closures.

Regards,
-- 
Rowan Collins
[IMSoP]