Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85250
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <550B5A81.1090706@gmail.com>
References: <CAAn=CzWySWQU1D93WA7L2eHvd31zogekEHmDUOsN7P6kBK4VrA@mail.gmail.com>
	<550B5A81.1090706@gmail.com>
Date: Thu, 19 Mar 2015 23:55:19 +0000
Message-ID: <CAAn=CzUZPo=Yy79pRbot58nSR_tFqKYpd53kaAMbfxyUvz9Lwg@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001a11c37f9cac7f2d0511acee45
Subject: Re: [PHP-DEV] RFC - Array slice syntactic sugar
From: bowersbros@gmail.com (Alex Bowers)

--001a11c37f9cac7f2d0511acee45
Content-Type: text/plain; charset=UTF-8

On 19 March 2015 at 23:23, Rowan Collins <rowan.collins@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.

--001a11c37f9cac7f2d0511acee45--