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?
Fixing
array_slicewould 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
Am 17.07.2018 um 07:35 schrieb Zeev Suraski:
Fixing
array_slicewould 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
And another:
$lengthis 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.
Fixing
array_slicewould 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() ?
Hi Levi, thanks for bringing this discussion.
Recently I've been scrutinizing array_slice. It's been painful.
For instance,
$preserve_keysis 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 calledpreserve_keysif 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:
$lengthis 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
$offsetparameter. 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_slicewould 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?--
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,
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_keysis 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 calledpreserve_keysif 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:
$lengthis 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
$offsetparameter. 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_slicewould 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?--
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.