Hi Leigh, Leigh wrote:
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 fact I don't think extract() even works on object properties. list() works with any "variable" (in the isset() sense).
I should really add some more examples to the RFC, so that it's more obvious that $this-> assignment is not the only thing this can or will be used for.
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).
So far I haven't actually heard anyone say they thought it would behave like (1), which is making me think that allowing arbitrary expressions would be fine. It'd be unfortunate to lock them out, because constants can't contain objects, so now you wouldn't be able to use list() with SplObjectStorage and such, and that would be a shame.
(2) is the only thing I was going to make it do anyway, (1) would mean list() functioning differently than it does at present.
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 :)
Oh, yeah, it's unfortunate that what the RFC currently proposes makes using initial offsets not possible. :/
The main reason I ended up disallowing mixed keys was because it complicates implementation if you have a some value that must be computed at runtime as a key (some constants, a variable, etc.), because now we can't hard-code the indexes of the following values into the opcodes. We don't know at compile-time that it'll be 5, 6, 7, we know it'll be $x, *maybe* $x + 1 (if $x was an index, otherwise it'll be the previous index), *maybe* $x + 2, etc.
The problem with disallowing mixed keys is it's inconsistent with the array literal syntax, and as you've demonstrated, it also is inconvenient for some use cases. As implemented, keyed list() is actually an entirely different parser branch from unkeyed list(). It's all a bit too arbitrary.
I may just have to allow mixed keys after all, even if it does make implementation a pain. I could add an exception for a leading offset, but that would have to have its own special rules. Better to just do things properly.
Thanks Andrea, looking forward to this.
I'm glad you like it! -- Andrea Faulds https://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
