[wp-trac] [WordPress Trac] #26673: Enhance wp_parse_args() by adding filters before/after the array_merge()

[WordPress Trac]

#26673: Enhance wp_parse_args() by adding filters before/after the array_merge()
-----------------------------------+------------------
 Reporter:  johnjamesjacoby        |       Owner:
     Type:  enhancement            |      Status:  new
 Priority:  normal                 |   Milestone:  3.9
Component:  Plugins                |     Version:
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |
-----------------------------------+------------------

Comment (by nacin):

 'request' isn't part of a utility function, though. It's an important part
 of WordPress. It's low-level API, but it isn't a utility. My point is
 there isn't a filter in array_merge(), either. Or wp_list_pluck(),
 wp_list_filter(), absint(), is_serialized(), add_query_arg(), path_join(),
 wp_send_json(), wp_parse_id_list(), wp_array_slice_assoc(), and that's
 just from skimming functions.php. wp_parse_args() is just a glorified
 array_merge(). (wp_parse_args() was written for a time when you could pass
 query strings to everything. A lot of newer instances of the function
 should possibly just be array_merge() instead, for where query string
 calls don't make sense.)

 Filters, in general, increase the maintenance burden on the codebase. If
 wp_parse_args() gained a filter, it would be extremely hard to keep usage
 of that filter backwards compatible, especially as functions evolve over
 time. If the filter was explicitly declared instead, it could A) have its
 own explicit documentation, B) be passed context based on other arguments
 of the function, C) allow the inputs and outputs of wp_parse_args() to be
 changed at will, based on evolution of the codebase.

--
Ticket URL: <http://core.trac.wordpress.org/ticket/26673#comment:6>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software