Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66447
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+9eiLu9f_gANN4az4gqG7L3Obf0dE2110fBUooOYt6bvxJy0A@mail.gmail.com>
References: <CAF+90c8o=0u3deM6LA6TW9GjDeNrZA_16TAPBmHJQ7mN_P4v+A@mail.gmail.com>
	<CA+9eiLugMVzK+9Cj+z__GW8y_F5D_L0SFRNazmDOMQyPJy2c5w@mail.gmail.com>
	<CAF+90c-=5AO-K1LmzmjKvJ_5vrzXsB9qic4bC73fw8GUmnosww@mail.gmail.com>
	<CA+9eiLu9f_gANN4az4gqG7L3Obf0dE2110fBUooOYt6bvxJy0A@mail.gmail.com>
Date: Sun, 3 Mar 2013 13:26:16 +0100
Message-ID: <CAF+90c--MhOsJqx6+CgvmtvWtyfd=hvMY0p65PR0xLSrErFGZA@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8fb1ed06cb73d204d70458dd
Subject: Re: [PHP-DEV] Allow (...)->foo() expressions not only for `new`
From: nikita.ppv@gmail.com (Nikita Popov)

--e89a8fb1ed06cb73d204d70458dd
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Feb 26, 2013 at 6:08 PM, Dmitry Stogov <dmitry@zend.com> wrote:

> On Tue, Feb 26, 2013 at 8:49 PM, Nikita Popov <nikita.ppv@gmail.com>wrote:
>
>> On Tue, Feb 26, 2013 at 7:41 AM, Dmitry Stogov <dmitry@zend.com> wrote:
>>
>>> Hi Nikita,
>>>
>>> I like the idea.
>>> But note, that it may cause some unexpected behaviour and bugs.
>>> I didn't test the patch I just guess it on my previous experience
>>> introducing similar features.
>>>
>>> - usage expression in write context (e.g. passing constant by reference)
>>>
>>> function foo(&$foo) {}
>>> foo("abc"[0]);
>>>
>>> - destruction of temporary result
>>>
>>> ($a . $b)[4]; // if ($a.$b) is destroyed?
>>>
>>> - in some cases destruction of temporary result may cause destruction of
>>> final result
>>>
>>> ((object)(array("a"=>"b")))->a = "c"; // temporary object may be
>>> destroyed before assignment
>>>
>>> All these edge cases must be carefully analyzed.
>>> I like the current patch, and in case the edge cases won't require many
>>> hacks, I'm all for it.
>>>
>>> Thanks. Dmitry.
>>>
>>
>> I just played a bit with it and came up with the following (additional)
>> patch to support use in write context:
>> https://github.com/nikic/php-src/commit/31705dd8c53efe3bb52d6aae483a324e5a511ae9It throws an error if the write is done on a TMP or CONST,
>>
>
> I like this patch more (it doesn't complicate executor).
>

This patch is on top of the other one, so the executor changes still apply.
This one is only about write-context, but the executor optype changes were
necessary for read-context (as in read-context CONST/TMP are valid, unlike
in write context).

However it doesn't handle BP_VAR_FUNC_ARG, where decision about read/write
> context must be done at run-time.
>

Good catch, I didn't consider that one (didn't even know it exists ^^).
This would require a few more changes:
https://github.com/nikic/php-src/commit/6f5483f006794dc78f8c341b1a6d7ad18c2e56be

Nikita

--e89a8fb1ed06cb73d204d70458dd--