If you want any evidence that terrible language design is alive and well in PHP, look no further than the new array_find function.
Not only is it yet another global function in a namespace already chock full of random array helpers, it is extremely similar in both name and usage to array_search - a global function since PHP 4. Except, of course, that in typical PHP fashion, array_find’s argument order is ($array, $filter_callback) while the older array_search is ($search_value, $array).
There are literally hundreds of hits for existing, global, functions named array_find. If these are loaded from a library, they will break uses of the new built-in function in exciting ways. Yet, even with this mentioned in the RFC (https://wiki.php.net/rfc/array_find) it seems to have been no obstacle whatsoever to its inclusion - despite the fact that the implementation is literally three lines of code.
I have to question if the benefits of this global function really outweigh the benefits. PHP devs claim that other languages have these functions so PHP should too - but neglect to note that most languages don’t make them global functions (rather, they’re usually array methods or in some utility module).
Your IDE should help you with the argument order if that's an issue for you. It has never been a problem for me and I don't understand the argument. I get that it might be confusing the few first times you use these functions, but if you use them every day you just remember the argument order.
The backward compatibility section found only 200-ish projects where array_find() was defined in global name space. For me that's a small price to pay for introducing the new function, and refactoring should BE easy when upgrading a project to PHP 8.4.
Adding array_find() to a namespace would be inconsistent. All other array_*() functions are global.
Can you elaborate? I'm not sure what you mean, but IDEs definitely make reading code easier. IDE does code formatting, highlighting, argument hints, jumping to methods, declarations, and various hover effects on variables, methods, and classes. Some IDEs offer call graphs and other more advanced tools. Not to mention static analysis that works out of the box in PHPStorm (and I'm sure it can be set up in VSCode).
I mean that no matter what you do, the arguments will always be shown in an inconsistent order and you’ll have to mentally swap them around. You probably could configure your editor to visually swap them, but that sounds like a really bad idea.
array_search() has the same needle, haystack order as in_array() or array_key_exists().
array_find() has a callback and takes the same order as array_walk() or array_filter().
It's just array_map() that's different, but that's because it can take multiple arrays.
And writing your own function with a prefix already used by PHP in the global namespace is just not a very good idea.
array_find parameter ordering is modeled after other non-variadic array functions, e.g. array_filter also having ($array, $callback) order.
But I agree, there is already some inconsistency, and when adding a new function you have to choose which function to make it consistent and which one to make it inconsistent with.
I had similar thoughts, but do appreciate the additional mb_ functions bringing multi byte support to some remaining functions.
Also people should be coding defensively with things like “if not defined” when implementing their own global helper functions (or avoid doing that at all)
"if not defined" doesn't help, if your own `array_find` doesn't have the same signature and semantics than the new global then you're screwed. You'd want the opposite: overwrite it if it already exists in the global scope (dunno if that's easy / how that'd work in PHP)
Not only is it yet another global function in a namespace already chock full of random array helpers, it is extremely similar in both name and usage to array_search - a global function since PHP 4. Except, of course, that in typical PHP fashion, array_find’s argument order is ($array, $filter_callback) while the older array_search is ($search_value, $array).
There are literally hundreds of hits for existing, global, functions named array_find. If these are loaded from a library, they will break uses of the new built-in function in exciting ways. Yet, even with this mentioned in the RFC (https://wiki.php.net/rfc/array_find) it seems to have been no obstacle whatsoever to its inclusion - despite the fact that the implementation is literally three lines of code.
I have to question if the benefits of this global function really outweigh the benefits. PHP devs claim that other languages have these functions so PHP should too - but neglect to note that most languages don’t make them global functions (rather, they’re usually array methods or in some utility module).