On سهشنبه ۱۸ اوت ۲۰۲۶، ۰۲:۳۳ mickmackusa <[email protected]> wrote:
> As a demonstration, this is new "top posted" text because the earlier > posted conversation in the thread exists below the newly written reply > text. [BAD] > > > On Tue, 18 Aug 2026, 08:36 سپهر محمودی, <[email protected]> wrote: > >> Hi Larry, >> >> [...] >> >> Regards, >> >> Sepehr >> > > This is new "bottom posted" text because the earlier posted conversation > in the thread exists above the newly written reply text. [GOOD] > > In the PHP Internals mailing list, you are expected to only "bottom post". > This rule is to allow easy human comprehension of the conversation. By > always bottom posting, the discussion in the thread of emails always reads > as oldest communication at the top and most recent at the bottom. Sepehr, > many of your recent emails have violated this simple rule. Please > permanently stop writing your replies with the historic content below your > new reply. > > Also, I am not a voting member of this organization, but I can say that > I've never had a professional project that required your proposed function > nor do I recall ever encountering a Stack Overflow question which would > benefit from your proposed function (and I have been a heavy curator of > php&arrays tagged content for many years). That doesn't mean that your > proposed function is worthless, I just haven't encountered a use case > personally. > > If a PHP array needed a pagination-style search function, should perhaps > the data structure be reconsidered? Is the data structure purpose-built or > is the function overcoming a suboptimal data structure? > > mickmackusa > Hi mickmackusa, Thank you for the feedback. First, I sincerely apologize for the bottom-posting mistake. I am new to the PHP Internals mailing list, and I’m still learning the rules. I will make sure to follow bottom posting correctly from now on. Regarding the use case: I agree that this function is not needed for small arrays, where array_slice() is perfectly fine. However, for very large arrays that are kept in memory (such as cached database results, log files read line by line, streaming data chunks, or paginated queues), array_slice() creates a full copy of the array. This copy costs both time and memory, and it grows with the size of the array. array_search_range() avoids this copy entirely, because it only searches within a range of the existing array without creating a new one. So while the use case may not be common on Stack Overflow, it does exist in real systems that work with large in-memory arrays. I’d be happy to hear more of your thoughts. Regards, Sepehr > >
