[wp-trac] [WordPress Trac] #49919: Explore renaming double underscore functions

[WordPress Trac]

#49919: Explore renaming double underscore functions
-----------------------------+-------------------------------
 Reporter:  desrosj          |       Owner:  (none)
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  General          |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  2nd-opinion      |     Focuses:  coding-standards
-----------------------------+-------------------------------
Description changed by SergeyBiryukov:

Old description:

> 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
> [https://www.php.net/manual/en/language.oop5.magic.php 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)?
>
> Previously: #46152, #48966.

New description:

 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
 [https://www.php.net/manual/en/language.oop5.magic.php 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)?

 Previously: #46152, #48966.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/49919#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform