Re: [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 <mickmackusa@gmail.com> 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 >