On 18 January 2016 at 12:35, Lester Caine <les...@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.
