Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90698
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <569CDC1C.2070304@lsces.co.uk>
References: <3B.E6.32157.D3DFA965@pb1.pair.com>
	<569C91FE.8030605@php.net>
	<569CDC1C.2070304@lsces.co.uk>
Date: Mon, 18 Jan 2016 12:56:02 +0000
Message-ID: <CAPwsocHULVMhCDP3AFviEg+LY5eXhd1qVd3CZnT_6jG7shV8bA@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001a11395ca8742e3705299b466c
Subject: Re: [PHP-DEV] [RFC] Allow specifying keys in list()
From: leight@gmail.com (Leigh)

--001a11395ca8742e3705299b466c
Content-Type: text/plain; charset=UTF-8

On 18 January 2016 at 12:35, Lester Caine <lester@lsces.co.uk> wrote:

> > Hi!
> >
> > I found the idea convincing from the first read, but maybe it's just my
> > mind's assumptions about list() that I dislike the resulting syntax,
> > yet, it seems to be the logical choice.
> >
> > So, maybe I'm just trying to say, that I don't like list() to be reused
> > for that, but I don't have any better idea otherwise.
>
> As someone still using 'extract' in legacy code, I can sort of see the
> logistics of this, but why not just extend 'extract' to use the current
> object rather than the symbol table. It already has handling for
> duplicate keys and to prefix the 'array' name to the resulting variables.


The uses for this extended syntax go beyond simply populating object
properties, and shoehorning it into extract would pretty much limit it to
this use-case.

In favour of this improvement, although I would very much like to see
variable keys too (second option makes the most sense to me, as it's in
line with the syntax).

How feasible would it be to add an exception to mixed keys? I'm thinking
list(7 => $a, $b, $c, $d) to specify an initial offset, similar to how you
can define an array as [7 => 0, 1, 2, 3]. This obviously goes hand in hand
with my desire for variable keys :)

Thanks Andrea, looking forward to this.

--001a11395ca8742e3705299b466c--