Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77627
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPwsocGF967ugDsACe0FALGJXY7NsgOT1TFAQE2sd2qxsskFaw@mail.gmail.com>
References: <CA+9eiLupqdnRWh3C=Q7Wa31NcDN_DUOa+uEXyAX78jcTn0OGcg@mail.gmail.com>
	<CAPwsocGF967ugDsACe0FALGJXY7NsgOT1TFAQE2sd2qxsskFaw@mail.gmail.com>
Date: Thu, 25 Sep 2014 15:15:59 +0400
Message-ID: <CA+9eiLuqfxBp-zQcc8aMFLAY53jHMsMu_PNSN6epdy62a+93KA@mail.gmail.com>
To: Leigh <leight@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0158a898dd98200503e1ec44
Subject: Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency
From: dmitry@zend.com (Dmitry Stogov)

--089e0158a898dd98200503e1ec44
Content-Type: text/plain; charset=UTF-8

disabling string handling would allow make operation simpler and would
improve regular access to array elements.
We won't need to check for (opline->extended_value & ZEND_FETCH_ADD_LOCK)
in FETCH_DIM_R handler.
However, it's going to be very small improvement, and I don't care a lot. :)

enabling string handling would require complication of
ZEND_FETCH_DIM_TMP_VAR handler (for strings support).
It's going to make list() handling a bit slower, but not significantly.

my choice +1 for disabling.

Thank. Dmitry.

On Thu, Sep 25, 2014 at 12:00 PM, Leigh <leight@gmail.com> wrote:

> On 25 September 2014 08:42, Dmitry Stogov <dmitry@zend.com> wrote:
> > Hi,
> >
> > The vote is opened at
> > https://wiki.php.net/rfc/fix_list_behavior_inconsistency
> >
> > Thanks. Dmitry.
>
> Since in the "should people be allowed to vote" thread, I said I think
> people should explain their votes, here is my explanation :)
>
> I am voting disable. +1 for consistency, but I think we already have a
> pretty rich suite of functions for working with strings that do not
> work with arrays, and vice versa. I think enabling list() to work on
> strings sets a precedent that more/all array handling mechanisms
> should be made to work with strings, and I'm not sure that's something
> we want.
>
> We've defined list as not working with strings in the manual, lets
> stick to our own definition.
>

--089e0158a898dd98200503e1ec44--