Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66244
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.52 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+9eiLugMVzK+9Cj+z__GW8y_F5D_L0SFRNazmDOMQyPJy2c5w@mail.gmail.com>
References: <CAF+90c8o=0u3deM6LA6TW9GjDeNrZA_16TAPBmHJQ7mN_P4v+A@mail.gmail.com>
	<CA+9eiLugMVzK+9Cj+z__GW8y_F5D_L0SFRNazmDOMQyPJy2c5w@mail.gmail.com>
Date: Tue, 26 Feb 2013 16:10:22 +0100
Message-ID: <CAF+90c-Kmx5=qqY3VpEDY+oPfDZ5acCSe_o0LcM6cA=FLMpauQ@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec54d475c7adf9904d6a20efb
Subject: Re: [PHP-DEV] Allow (...)->foo() expressions not only for `new`
From: nikita.ppv@gmail.com (Nikita Popov)

--bcaec54d475c7adf9904d6a20efb
Content-Type: text/plain; charset=ISO-8859-1

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.
>

All these edge-cases are covered by not being allowed :) The old (new
Foo)->bar syntax did not allow usage as a variable and I stayed with that.
I.e. (expr)->xyz will still be an expression, not a variable and as such
(expr)->xyz = 'foo' will be a syntax error.

I stayed with the old behavior because I thought that it would just be a
small bugfix-like change that way, whereas allowing usage in write-context
could require larger changes (though I haven't tried, maybe its just as
simple). But now that everybody seems to think that this is a major change
that requires serious consideration, I guess I can have a look at the
write-context use too :)

Nikita

--bcaec54d475c7adf9904d6a20efb--