Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77638
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54248E27.1040206@sugarcrm.com>
References: <CA+9eiLupqdnRWh3C=Q7Wa31NcDN_DUOa+uEXyAX78jcTn0OGcg@mail.gmail.com>
	<CAPwsocGF967ugDsACe0FALGJXY7NsgOT1TFAQE2sd2qxsskFaw@mail.gmail.com>
	<CA+9eiLuqfxBp-zQcc8aMFLAY53jHMsMu_PNSN6epdy62a+93KA@mail.gmail.com>
	<CAF+90c9ZKzFVozJpu3m54QM4=J22qgoLJ82NKr87v9jN=F3vpA@mail.gmail.com>
	<CAF+90c-30p5X2g1D-0fda-1pvGzta+QM5ETSra=1GdS9b=Y_7A@mail.gmail.com>
	<CA+9eiLvtub7jzW1_-2CThkABEfZ01W7Uz6Fx3n7QU2SrsMtR-Q@mail.gmail.com>
	<54248E27.1040206@sugarcrm.com>
Date: Fri, 26 Sep 2014 00:09:49 +0200
Message-ID: <CAF+90c_a7fGh5soaoQuwA2QN4em7hy0wr6hH+zTWXnEq4B_3MQ@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Dmitry Stogov <dmitry@zend.com>, Leigh <leight@gmail.com>, 
	PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b8737622470280503eb0fff
Subject: Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
From: nikita.ppv@gmail.com (Nikita Popov)

--047d7b8737622470280503eb0fff
Content-Type: text/plain; charset=UTF-8

On Thu, Sep 25, 2014 at 11:50 PM, Stas Malyshev <smalyshev@sugarcrm.com>
wrote:

> Hi!
>
> > It was on design. list() was intended to support plain arrays only.
>
> I'm not sure I'm getting this point - why list($a, $b) = $foo is not
> just translated as $a = $foo[0], $b = $foo[1], etc.? Is it hard to make
> it work that way?
>

That's exactly what list() does. The only catch is that $foo here is reused
multiple times and mustn't be freed in the meantime (for the cases where
$foo is some complex expression resulting in an VAR or TMP_VAR operand).
That's what the ZEND_FETCH_ADD_LOCK flags for FETCH_DIM_R does - it does
$foo[0] without freeing $foo.

However back when list() was introduced FETCH_DIM_R didn't support CONST or
TMP_VAR operands, so instead these two used a separate FETCH_DIM_TMP_VAR
opcode, which supports only arrays and not strings or objects. Support for
CONST|TMP in FETCH_DIM_R was only added in PHP 5.5 as part of constant
string/array dereferencing.

Long story short, because FETCH_DIM_R now supports CONST and TMP_VAR
operands, we can always use it and FETCH_DIM_TMP_VAR can be dropped -
that's all that has to be done in order to always support strings and
objects in list(). (I've linked a patch for this previously, see
https://github.com/nikic/php-src/compare/stringOffsetsInList).

If I understood it correctly, then Dmitry's alternative is to add support
for CV and VAR operands to FETCH_DIM_TMP_VAR and always use that for
list(). This avoids having to check the ZEND_FETCH_ADD_LOCK flag in
FETCH_DIM_R. However I don't think that this optimization is related to
whether or not we support strings and objects. We can have a separate
opcode only for list() in either case, no matter which choice is made here.

Nikita

--047d7b8737622470280503eb0fff--