#39240 closed enhancement (wontfix)
Add a generic return value function
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.8 |
Component: | General | Keywords: | |
Focuses: | Cc: |
Description
This topic kicked off some healthy discussion on Twitter, so it seemed appropriate to just open a ticket for the idea to develop further.
Since the second parameter in add_filter()
can only accept a callback function, we've gotten used to having to go out of our way to define them. This was OK for a while, but has created some other baggage too, like more functions living in the global scope, people just lazily using the filter's tag as their callback name, which means increased chances of naming collisions, and not to mention just more lines of code in everything.
I think it might be good to consider adding a generic return value function to core that would complement the existing __return_*()
family.
Since we will never be able to do what feels natural in these situations:
add_filter( 'twentyseventeen_front_page_sections', 6 ); add_filter( 'site_icon_sizes', array( 256, 128, 64 ) ); add_filter( 'rss_update_period', 'daily' );
Passing the values through a generic return wrapper could be a nice alternative:
add_filter( 'twentyseventeen_front_page_sections', __return( 6 ) ); add_filter( 'site_icon_sizes', __return( array( 256, 128, 64 ) ) ); add_filter( 'rss_update_period', __return( 'daily' ) );
Weston Ruter demonstrated how this could be done while still maintaining 5.2 compatibility, though it requires the use of create_function()
.
Maybe we can't take this seriously until 5.3 is on the table, at which point closures basically solve everything. But even so, I still kind of like the idea of a generic __return()
since it's clean and fits nicely into a pattern we've already started.
Change History (6)
#2
@
8 years ago
Since we're actively trying to remove create_function
from core (#37082), -1 on the implementation here. You can use classes to avoid needing it, but I don't see that core has a real need for it.
In 5.3+, function () { return 42; }
is pretty short, or you can create your own wrapper pretty easily:
function __return( $value ) { return function () use ( $value ) { return $value; } }
IMO, there's no need for this in core, +1 for close.
#3
follow-up:
↓ 4
@
8 years ago
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
This can be achieved without create_function()
and without magic getters or any other type of hack (see https://gist.github.com/johnbillion/a5113d0362fb5238742bf773d3da9c4f), but I don't think this belongs in core. It's kind of an anti-pattern, and makes code hard to debug and unhook when you've got unreferenceable callback functions hooked in.
#4
in reply to:
↑ 3
@
7 years ago
Replying to johnbillion:
This can be achieved without
create_function()
and without magic getters or any other type of hack (see https://gist.github.com/johnbillion/a5113d0362fb5238742bf773d3da9c4f), but I don't think this belongs in core. It's kind of an anti-pattern, and makes code hard to debug and unhook when you've got unreferenceable callback functions hooked in.
nice implementation of __return()
, thank you for sharing!
IMHO; This is probably best left for 5.3+ only, and I'd argue that anonymous functions really cover it far enough not to need a wrapper..