Re: [PHP-DEV] [RFC] [Discussion] array_match

در تاریخ دوشنبه ۲۴ اوت ۲۰۲۶، ۰۳:۱۷ mickmackusa <[email protected]> نوشت:

> I just want to add a few points to the discussion.
>
> With an increasing number of software developers offloading code writing
> to AI, there's probably a decreasing weight to which "ergonomics" can be
> argued. Don't get me wrong, I love concise and elegant code, but not for
> _code golfing_ reasons and there are diminishing returns in such adventures.
>
> As for performance arguments, we need to see real benchmarks versus
> related processes returning the same result to understand the amount of
> performance gains. We may also need to understand if there are thresholds
> where the performance differences are more/less noticeable.
>
> This proposal is coupling one iterating function with one string function.
> Think about the precedent adopting this proposal would set. Would the
> language slip into bloating its array function family with tens of other
> combinations _for performance/ergonomic reasons_?
>
> I am not in favor of the array_match() or array_str_contains() proposals,
> but an alternative not surfaced in this thread is the idea of polymorphism
> with the already existent str_contains() function. In other words, make it
> behave like str_replace() whether a haystack parameter is a string or an
> array of strings. I don't know if the language is trying to avoid such a
> convention, but I know I've personally wished that `preg_quote()` could
> directly receive an array of strings before imploding its result with pipes
> (and I've seen countless php-regex posts on Stack Overflow of array_map()
> making preg_quote() calls before imploding).
>
> While it is completely natural to muse language modifications based on our
> own encounters with development, before devoting time to a proposal, sense
> check that the change would significantly improve the language and benefit
> a significant number of developers and codebases.  Maybe take time to
> silently draft 3 to 5 distinctly different proposals, then critically
> compare and rank them from most to least compelling for general developers,
> then deliver your best proposal. Such an exercise will help you to
> self-evaluate which proposal(s) are ready to share with the internals
> mailing list, which ones need more consideration, and which ones might
> never become compelling proposals.
>
> Sincerely,
> mickmackusa
>

-----------

Hi everyone,

Thank you all for the valuable feedback on the `array_str_contain` proposal
so far.

Based on the recent technical discussions, especially regarding Unicode
handling and performance (thanks Yuya for the insights), I am focusing the
design on a UTF-8 by default approach. This will ensure full and efficient
support for non-Latin characters and emojis, which aligns perfectly with
modern web standards.

I am currently refining the implementation and will update the RFC details
accordingly. In the meantime, if anyone has specific edge cases regarding
this UTF-8 approach that I should keep in mind during testing, I would be
happy to hear them.

Thanks again for your time and guidance.

Best regards,
Sepehr