[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 johnjamesjacoby):

 Replying to [comment:6 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 (...)
 I understand your points, and still believe because of the way we use
 `wp_parse_args()` that it's a fine candidate for the type of dynamic
 filtering that's relatively common through-out the codebase already, in:
 WP_Customize_Setting::value(), get_option(), update_option(),
 get_user_option(), map_meta_cap(), get_the_term_list(), comment_form(),
 get_file_data(), add_metadata(), update_metadata(), etc...

 > 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.)
 I understand that, and the history, and still think there's an opportunity
 to provide developers a more forgiving and flexible experience.

 > Filters, in general, increase the maintenance burden on the codebase.
 I agree that hardcoded ones do. I disagree that filters in functions like
 get_option() have burdened anyone.

 > 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.
 How so? The luxury of using array_merge() and wp_parse_args() is
 flexibility with arguments without worrying about traditional function and
 method parameters being deprecated, out of order, etc...

 > If the filter was explicitly declared instead, it could A) have its own
 explicit documentation,
 We can document filters above calls to `wp_parse_args()` the way we do
 with apply_filters().
 > B) be passed context based on other arguments of the function,
 This is a minor limitation compared to overall gains IMO.

 > C) allow the inputs and outputs of wp_parse_args() to be changed at
 will, based on evolution of the codebase.
 They already can be now, and this enhancement doesn't inhibit that in any
 way other than adding an additional parameter to `wp_parse_args()` which,
 ironically, is what makes using it great.

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