[wp-trac] [WordPress Trac] #46635: Improve identifying of non–trivial callbacks in hooks

WordPress Trac noreply at wordpress.org
Wed Apr 3 05:51:14 UTC 2019

#46635: Improve identifying of non–trivial callbacks in hooks
 Reporter:  Rarst        |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:  coding-standards

Comment (by giuseppe.mazzapica):

 Yes, signatures are "fragile". Using the declaring file as identifier
 `some-file.php/function()`, like would be more stable: the fact that a
 closure is moved from a file to another can not be assumed to be more
 frequent than a function that changes name.

 However, that would require Reflections which means that to store the
 serialization upfront would be a potentially big waste of resources having
 to serialize ''any'' closure, even if chances are high none will be
 removed. On the other hand, not storing upfront means that removing will
 be quite expensive having to loop the potential dozen of callbacks added
 to a given hook, and using Reflection anytime a closure is encountered.

 For me, the best scenario is when the developer can pass an unique
 identifier for the closure, that will be fast, reliable, and very future
 proof, even *more* than current situation: the actual callback added can
 **completely** change (even not being a closure anymore), but as long as
 the identifier is the same, code that removes the callback don't need to

 Being an additional optional argument this does not pose any backward
 compatibility issues.

 Again, I see something like this:

     function ( $post_ID, $post ) {
       // ...

 as the best solution: removing this closure will be easy, reliable, future
 proof and performant.

 A WPCS rule could be added to encourage usage of this identifier when
 closures are used as callbacks, and in case core will ever use closures
 for hooks, it should follow that guideline.

Ticket URL: <https://core.trac.wordpress.org/ticket/46635#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

More information about the wp-trac mailing list