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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.