Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Replacing array_slice »

Replacing array_slice

php.internals

Levi Morrison

8 years ago
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?

Zeev Suraski

8 years ago
> On 17 Jul 2018, at 7:12, Levi Morrison <levim@php.net> wrote: > > 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`?
array_carve()? array_chisel()? Zeev

Enno Woortmann

8 years ago
Am 17.07.2018 um 07:35 schrieb Zeev Suraski:
>> On 17 Jul 2018, at 7:12, Levi Morrison <levim@php.net> wrote: >> >> 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`? > array_carve()? array_chisel()? > > Zeev >
If keeping it together in a single function maybe array_extract() will do the job. Or do you think it's to close to the naming of extract() and may lead to confusion? Enno

Jesse Schalken

8 years ago
On Tue, Jul 17, 2018 at 2:11 PM, Levi Morrison <levim@php.net> wrote:
> And another: `$length` is a length when it's a positive number, but > it's an offset from the end when it's negative. >
That's how substr() works, so it's at least consistent with that. It makes a lot more sense if you think of it as $array->drop($offset)->take($length), where both ->drop() and ->take() add the array's length if the argument is negative.

rich gray

8 years ago
On 17/07/2018 05:11, Levi Morrison wrote:
> 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`? >
array_chop() ?

Gabriel Caruso

8 years ago
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,

Levi Morrison

8 years ago
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`.