Re: [PHP-DEV] [RFC] array_search_range() function

Hi mickmackusa and everyone,

Thank you for your time and the detailed feedback on the
"array_search_range" RFC.

Given the valid concerns and the strong opposition raised during the
discussion, I have decided to officially withdraw this RFC. I really
appreciate the time you all took to review and discuss it.

I am taking this as a valuable learning experience and hope to come back
with a better and more useful function proposal for PHP in the near future.

Best regards,
Sepehr


On پنجشنبه ۲۰ اوت ۲۰۲۶، ۰۰:۴۴ mickmackusa <[email protected]> wrote:

> 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
>