Re: [PHP-DEV] [RFC] [Discussion] array_match
[email protected] (mickmackusa)
| Newsgroups | php.internals |
|---|---|
| Message-ID | <CAKVXxD_ayStLGEfmFtvVuG6PLEPKP4m3RZjm78cTNtJmAUm_-Q@mail.gmail.com> |
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