On 19 March 2015 at 23:23, Rowan Collins <rowan.coll...@gmail.com> wrote:
> On 19/03/2015 20:49, Alex Bowers wrote: > >> My proposal is something similar to Pythons slice, in PHP this would look >> like: >> >> $slided = $array[1:4] >> >> This will get the elements in positions 1,2,3,4. (1 through 4 inclusive), >> ignoring the actual key of the array. The result for an array will be an >> array with the keys preserved, in the same order. >> > > While I can see the reasoning for not looking into the actual keys (which > might not have a logically sliceable order), I think the syntax needs to be > more distinct, because this seems a bit confusing: > > $countdown = [ 5 => 'Five!', 4 => 'Four!', 3 => 'Three!', 2 => 'Two!', 1 > => 'One!', 0 => 'Zero!' ] > > $countdown[0]; // 'Zero!' > $countdown[0:0]; // ['Five!'] > $countdown[0:][0] // 'Zero!' > $countdown[:0][0] // null - slice contains no key 0 > > The problem is that the slice access looks like an extension of key > access, but is actually a new concept of positional element access. With a > slight tweak to syntax, such as adding an @, we could make positional > access available for non-slices as well: > > reset($countdown); // Five! - a common way of getting the first element > positionally > $countdown[@0]; // 'Five!' > $countdown[@1]; // 'Four!' > $countdown[@0:0] // ['Five!'] > $countdown[@0:1] // ['Five!', 'Four!'] > $countdown[@0:][@0] // 'Five!' > $countdown[@:0][@0] // 'Five!' > > > A side addition, that may be considered is adding [-1] to get the last >> item >> in the array. But that is not a main part of this RFC. >> > > This would actually be a really important addition for me, but only if I > can do it on a non-slice, as above: > > $countdown[-1]; // null - no such key > end($countdown); // 'Zero!' - common way of getting last element > $countdown[@-1]; // 'Zero!' - positional access counting from the end > $countdown[@-2]; // 'One!' - fiddly to do in current PHP > > > I just wrote out all those examples and realised that it may not be > possible to reuse @ in this context. Finding new symbols to use for syntax > is hard. :( > > Regards, > > -- > Rowan Collins > [IMSoP] > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > While I can see the reasoning for not looking into the actual keys (which > might not have a logically sliceable order), I think the syntax needs to be > more distinct, because this seems a bit confusing: > $countdown = [ 5 => 'Five!', 4 => 'Four!', 3 => 'Three!', 2 => 'Two!', 1 > => 'One!', 0 => 'Zero!' ] > $countdown[0]; // 'Zero!' > $countdown[0:0]; // ['Five!'] > $countdown[0:][0] // 'Zero!' > $countdown[:0][0] // null - slice contains no key 0 > Thats a good point, something else that just came to me; your example of $countdown[0:0]; if we had it as inclusive indexes, then this would actually give you ['Five!', 'Five!'], which is unlikely to be what was desired. What would be a good solution to this? 1) The range cannot be 0 in length (such that, from - to must be > 0) - This would also get around issues of people trying to use it like so : $countdown[5:3], as the expected outcome of that should be a fatal error. Also, your use-case of 0:0 would be better placed simply using $countdown[0]. The issue with this solution would then come that if there was any code for this range being dynamic, some logic would have to take place on the users side to ensure that $from and $to differ by at least +1 To me, this isn't really a big issue, since I cannot see this being that big of a use case, but it is worth mentioning. To me, a larger use case would be a user wanting say, the first N items from an array, and so using $sub_array = $array[: (N-1)], which can then be easily used within a foreach loop, without the need for $key to be used and breaking out of the foreach loop on the Nth iteration. The problem is that the slice access looks like an extension of key access, > but is actually a new concept of positional element access. With a slight > tweak to syntax, such as adding an @, we could make positional access > available for non-slices as well: I think the use of the @ symbol would be misplaced for this; it already has a meaning within PHP, and many people are often taught to shy away from it (due to previous bad coding practices using it heavily); and so this feature might suffer by association even though the symbol means something completely different. A different symbol is certainly a possibility; but this is something that happens nowhere else (ignoring the & by reference) in PHP, and feels like it isn't the best solution to the problem. Other languages that implement this do not require a prefixed symbol, and I don't see the need for PHP to have one. There may be some confusion; but that will be displaced over time. 2) Would a possible solution to this be just to make it explicitly clear in the documentation that this *does not* refer to the keys, and instead the array positions? > > >> A side addition, that may be considered is adding [-1] to get the last > item > >> in the array. But that is not a main part of this RFC. >This would actually be a really important addition for me, but only if I > can do it on a non-slice, as above: To me, whilst I certainly want this part in it, I don't want to overload the RFC with things that aren't core to the feature, which may be cause for rejection if it makes it to a vote; I may do this as a successor-vote. Feel free to make it its own RFC if you want.
