[wp-trac] [WordPress Trac] #23259: Allow filtering the $function parameter of add_filter(), has_filter() and remove_filter()

[WordPress Trac]

#23259: Allow filtering the $function parameter of add_filter(), has_filter() and
remove_filter()
------------------------------------+------------------------------
 Reporter:  MikeSchinkel            |       Owner:
     Type:  feature request         |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Plugins                 |     Version:  3.5
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |
------------------------------------+------------------------------
Changes (by MikeSchinkel):

 * cc: mike@… (added)


Comment:

 Replying to [comment:2 nacin]:
 > This sounds clever, but:
 >
 >  * It proposes a solution at the onset, rather than the problem.

 I thought that's what trac was for, to post code which is a solution by
 nature?

 I sometimes feel I'm damned if I do, damned if I don't...

 >  * If the plugin author would need to do something special to support
 it, what is the benefit to this, over better education of developers to
 ensure they expose object references (when not just using static methods
 , which is even easier)?

 Did you read the commenter's comments? His issue wasn't with developers
 who expose, it was that when they expose it's complicated for someone who
 is not a full time developer to grok how to work with it.

 The problem I'm trying to solve here is one of complexity for the site
 builder, not the need for plugin developers to do a better job ''(I myself
 can already do what's needed to expose those object references, I just
 blogged about it after all.)''

 I want to be able to build plugins that are very easy for site builders to
 use, and this commenter pointed out that if we use classes ''(he thinks,
 and currently he's right)'' that means it's going to be harder for him to
 work with.

 >  * This masks the simple callback nature of the second argument,
 potentially making it more difficult to read a plugin, especially if one
 is less familiar with WP.

 True. But then people who are not familiar with WP won't know what
 `add_filter()`, `has_filter()` and `remove_filter()` actually do before
 they read the code for those functions.

 Maybe alternate solution would be to have anything prefixed with '@' to a
 special case, or something like that.

 >  * How would you avoid obvious recursion issues in core? And in the
 plugins themselves?

 Good point.

 When I started writing this up I was only trying to fix the
 `remove_filter()` use case and for that I considered the recursion issue
 but when I expanded to include more than`remove_filter()` I forgot to
 consider it.

 Assuming this would be considered in general then the solution is to
 disable applying filters for this one hook.

 >  * This would potentially slow down an API that needs to be very fast
 because it is called so often. Worse, performance would degrade further as
 more plugins opt into these filters.

 True.  Well if the we only considered a string and first character were an
 indicator it would be a very fast check before running the filter. I've
 uploaded another patch for consideration.

 And if not would you consider it if we limit the scope to
 `remove_filter()` then, as that's where the issue arose?

 Better yet, could you read the comments on that post and see if you can
 come up with a better solution to empower plugin developers to address the
 commenter's concerns?

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