Opened 5 years ago
Closed 5 years ago
#49919 closed feature request (wontfix)
Explore renaming double underscore functions
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | General | Keywords: | 2nd-opinion close |
Focuses: | coding-standards | Cc: |
Description (last modified by )
Adding the PHP Compatibility checker to Core's Travis builds in [46290] exposed many false positives and non-controversial fixes required for maximum compatibility that could easily be made. But there were also a few practices in Core that have the potential to be problematic in future versions of PHP that more detailed require discussion and planning.
The PHPCompatibility.FunctionNameRestrictions.ReservedFunctionNames
sniff re-exposes the names of Core's double underscore functions (__return_*
, for example) as a potential future conflict with new magic methods (these were previously set to be ignored by the WordPress.NamingConventions.ValidFunctionName
sniff in [45580]).
Caution: PHP reserves all function names starting with
__
as magical. It is recommended that you do not use function names with__
in PHP unless you want some documented magic functionality.
The functions are:
__get_option()
__clear_multi_author_cache()
__ngettext()
__ngettext_noop()
__return_true()
__return_false()
__return_zero()
__return_emtpy_array()
__return_null()
__return_empty_string()
__checked_selected_helper()
Continuing the discussion from #46152 (comment below is from @jrf):
While I understand and agree they should be ignored for now, I do think we should probably open an issue about deprecating these functions/methods in favour of the same functions, but then with better names.
I know this will be a pain, especially for methods like
__return_true
etc, but we kind of need to take that pain at some point, so why not now (or at least in the near foreseeable future)?
Change History (7)
#3
follow-up:
↓ 4
@
5 years ago
In practice, WordPress has enough weight (and market share) to simply push back on any potential new functions in PHP core that clash with existing functions of the same name in WordPress. I don't think there's much value in deprecating these.
#4
in reply to:
↑ 3
@
5 years ago
Replying to johnbillion:
In practice, WordPress has enough weight (and market share) to simply push back on any potential new functions in PHP core that clash with existing functions of the same name in WordPress. I don't think there's much value in deprecating these.
I tend to agree.
If we were to tackle this, here is a rough draft plan of steps:
trunk
and publish another post on Make Core reminding everyone that the functions will be deprecated in X.3.__
style functions.