Re: Replacing array_slice
| From: | Levi Morrison | Date: | Wed, 18 Jul 2018 01:13:39 +0000 |
| Subject: | Re: Replacing array_slice | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-102906@lists.php.net to get a copy of this message | ||
On Tue, Jul 17, 2018 at 6:24 AM Gabriel Caruso
<carusogabriel34@gmail.com> wrote:
>
> Hi Levi, thanks for bringing this discussion.
>
>> Recently I've been scrutinizing array_slice. It's been painful.
>>
>> For instance,
$preserve_keys is totally ignored for string
>> keys.
>> This was undocumented until Christoph integrated it 2-3 days ago
>> (thanks, cmb). However, this is really not a good design decision: why
>> have a parameter that is called preserve_keys if the data
>> gets the
>> final say, especially since there isn't any technical requirement for
>> this?
>>
>> Here's another "fun" behavior: negative offsets whose absolute values
>> are larger than the size of the array (eg the array has 3 elements and
>> you pass an offset of -5) will shift the window to begin at zero
>> instead of truncating the out-of-range values (which is what happens
>> on the positive side).
>>
>> And another: $length is a length when it's a positive
>> number, but
>> it's an offset from the end when it's negative. You could perhaps
>> convince me that when length is positive it's an offset from the
>> $offset parameter. However, if you look at the design of
>> slicing
>> functions in other languages (eg Python, Ruby, JavaScript) they take
>> beginning and ending offsets, not a beginning offset and a length.
>>
>> And another: it always iterates from the beginning of the array even
>> if you are only interested in the last half (somewhat common for
>> various algorithms that split things in half).
>>
>> Fixing array_slice would probably do more harm than good at
>> this
>> stage. Instead I would like to provide an alternative function that
>> does not have all this baggage, and will have decent performance much
>> of the time. The best ideas I have for names are not that great:
>>
>> - array_real_slice?
>> - array_slice2?
>>
>> We could also split it into 2 functions, one that preserves keys and
>> one that doesn't, instead of using a parameter. Any ideas there?
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> A while ago I come up with this discussion in my Twitter, not with a new function, but with a
> new "operator":
> https://twitter.com/carusogabriel/status/974610078807613443
>
> What do you think?
>
> Thanks,
I think slicing can potentially be a good feature, but there is a lot
more design space for this than there is for just adding a new
function. Given the other things I have on my plate right now I don't
want to start another feature; someone else is welcome to try.
"chop" in some other languages effectively means removing leading or
trailing members - this would be misleading here.
array_extract has no relation to extract, which might be
confusing. It might be okay.
What about array_subslice for a name? People might initially be
curious about having both array_slice and array_subslice, which
will hopefully lead them to reading documentation that
array_subslice is preferred, but that there are no current plans to
remove array_slice.