Hi Sepehr, I've taken some time to review your proposal more thoroughly and
I have some feedback.
1. Is the example in your RFC for a large array of database data an XY
Problem?
My first instinct would be to build pagination into the query itself
rather than process the result set data.
2. Is the example in your RFC for a large array of filesystem data an XY
Problem?
Should the script which calls `file()` actually do the following to
avoid loading the unwanted portions of data in the first place?
```php
$file = new SplFileObject('access.log');
$file->seek(100000);
$end = 200000;
while (!$file->eof() && $file->key() < $end) {
if (str_contains($file->current(), 'ERROR')) {
echo $file->key();
break;
}
$file->next();
}
```
3. I'm still not convinced that slicing a copy of the array is necessary
and your proposal seems to be founded on that premise.
The enormous data payload is already loaded into memory, it just needs
to be iterated.
Why can't you use a foreach and conditionally continue/break the loop
while searching?
In a scenario which involves an indexed array, a for() loop can be used,
but for utility a foreach() is more suitable.
```php
if (!function_exists('array_search_range')) {
function array_search_range(
mixed $needle,
array $haystack,
int $offset = 0,
?int $length = null,
bool $strict = false
): int|string|false {
$count = count($haystack);
if ($offset < 0) {
$offset = max(0, $count + $offset);
}
if ($length === null) {
$length = $count - $offset;
} elseif ($length < 0) {
$length = $count - $offset + $length;
}
if ($length <= 0 || $offset >= $count) {
return false;
}
$position = 0;
$end = $offset + $length;
foreach ($haystack as $key => $value) {
if ($position >= $end) {
break;
}
if ($position >= $offset) {
if ($strict ? $value === $needle : $value == $needle) {
return $key;
}
}
++$position;
}
return false;
}
}
```
4. I am not a fan of "falsible return values" because I prefer to null
coalesce in my code and that is the reason that I try to avoid old native
PHP functions that return false on an unsuccessful process.
I can appreciate that you are trying to maintain consistency with
array_search() - which I almost never use because value-searching an array
is seldom the most efficient process.
5. Is your proposed function name ideal?
The coding intention is to hybridize `array_search()` and
`array_slice()`, so shouldn't it be `array_slice_search()` or
`array_search_slice()`?
The "range" in the function name might mislead developers into believing
that the function searches for a range of needles.
6. If your coding intention is to meaningfully interrogate portions of
an enormous array and performance is a concern, then perhaps it is time to
consider partitioning the enormous array into smaller, more manageable
chunks or a more searchable map.
On relatively small arrays, I find this proposal even less compelling.
Ultimately, I still feel that this RFC is solving a problem that should
usually be mitigated by an earlier refactor.
7. I find the last line under the "Why This Function Is Worth It" to be
unusual. "Available now: usable today, not after a multi-month RFC"
...well, it's not usable today - it will need to go through the RFC vetting
process and then get implemented. Your statement feels like unnecessary and
misleading marketing speak.
While I can imagine there might be a few developers who can benefit from
this RFC, I remain unconvinced that this function would be widely used by
PHP developers.
mickmackusa
