Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#49919 closed feature request (wontfix)

Explore renaming double underscore functions

Reported by: desrosj's profile desrosj Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords: 2nd-opinion close
Focuses: coding-standards Cc:

Description (last modified by SergeyBiryukov)

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)?

Previously: #46152, #48966.

Change History (7)

#1 @SergeyBiryukov
5 years ago

  • Description modified (diff)

#2 @desrosj
5 years ago

If we were to tackle this, here is a rough draft plan of steps:

  1. In release X.1, introduce functions with the new, future proof names, accompanied with a dev note explaining why the new functions are being changed, how to update code, and encouraging all plugin/theme developers to update their code base accordingly.
  2. Let that sit for one more additional major release (X.2).
  3. After X.2 is released, deprecate the functions in trunk and publish another post on Make Core reminding everyone that the functions will be deprecated in X.3.
  4. X.3 is released officially deprecating the old __ style functions.

#3 follow-up: @johnbillion
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 @SergeyBiryukov
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.

#5 @desrosj
5 years ago

I think I also agree with that stance. @jrf felt a bit more strongly in the other direction, though, so let's leave this for a bit more discussion.

#6 @desrosj
5 years ago

  • Keywords close added

Adding recommendation to close pending another opinion.

#7 @johnbillion
5 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.