[wp-trac] [WordPress Trac] #58962: Provide a way to load multiple specific options with a single database request

[WordPress Trac]

#58962: Provide a way to load multiple specific options with a single database
request
-------------------------------------------------+-------------------------
 Reporter:  flixos90                             |       Owner:  flixos90
     Type:  enhancement                          |      Status:  reopened
 Priority:  normal                               |   Milestone:  6.4
Component:  Options, Meta APIs                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests has-dev-    |     Focuses:
  note dev-reviewed                              |  performance
-------------------------------------------------+-------------------------

Comment (by flixos90):

 Trying to decouple the two discussions we're having here. While in the
 long term we'll probably open another ticket to revisit the naming
 holistically, for this ticket and the 6.4 release I think we're trying to
 decide on two questions:
 1. Should we prefix the functions with an underscore?
 2. Should we use the term "prime" or the term "load"?

 Both questions partly have to do with consistency with some existing
 functions.

 Let me try to summarize my thoughts on question 2 first ("prime" vs
 "load"):
 * I think "load" is a more accessible (as in easier to understand) term
 than "prime".
 * FWIW, I am not a native English speaker, and a lot of WordPress
 developers aren't, but I certainly know what "load" means as it is a very
 common verb that even non developers are exposed to. You see it all the
 time even when ''using'' software.
 * For "prime", that is not the case. I honestly do not know even now what
 the verb "prime" means, as in I wouldn't be able to tell you the German
 translation of that word. The only reason that I know what the "prime
 cache" functions do because I am familiar with their code. The only
 meaning I know of the word "prime" is for the mathematical number meaning.
 * Whether we hide the word "caches" from the function name or not isn't
 that important to me. But to me something like `wp_load_x_caches()` is
 clearly more meaningful than `wp_prime_x_caches()`.

 Summarizing my thoughts for question 1 (the underscore prefix):
 * While the discussion on wording to use for the function has no "right or
 wrong", prefixing a public function with an underscore is simply wrong as
 it violates a common software engineering expectation that a underscore-
 prefixed function is not intended for public usage, as @hellofromTonya
 outlined in [comment:20].
 * That said, I am quite certain all of us are aware of that, so the only
 argument ''for'' prefixing with an underscore is consistency.
 * To me however, this is consistency going too far. Why introduce poorly
 named functions just because there are related existing poorly named
 functions? (I realize that for the existing ones the implications are
 different since they only became public over time.)
 * I also question that consistency is a strong argument here, given there
 is another set of functions such as `wp_load_alloptions()` that also is
 closely related to the new functions introduced here, and the current
 naming would be consistent with those existing functions. So IMO we're
 also discussing with ''which'' set of existing functions to achieve naming
 consistency.
 * Specifically to the existing `_prime_*_caches()` functions, there is one
 distinct difference to the functions introduced here which is a
 counterargument against these functions doing the same thing:
     * The existing functions are all about priming database entities,
 which can be created by the end user, also sometimes referred to as
 "object types" in WordPress. Options are different, as the option names
 that exist are entirely defined by code.
     * This becomes particularly relevant when looking at the
 `wp_load_options_by_group()` function: This function would not make any
 sense in the context of the existing `_prime_*_caches()` functions. Sure,
 we could in theory have a function like
 `_prime_post_caches_by_post_type()`, but that would not be scalable as
 users can create an infinite number of posts, and the same applies to any
 other entities covered by the `_prime_*_caches()` functions. For options,
 that concern doesn't apply. They are controlled by code, and a single
 option group is extremely unlikely to have let's say more than 100 options
 (I think that's already a very high number for a single option group).

 As a summary, I think the conversation about "prime" vs "load" is probably
 best held in the follow up ticket where we revisit the naming
 holistically, and while I have shared my preference and rationale I'm not
 going to get hung up on that for the short term solution, as in this
 ticket.

 For the underscore though, I strongly object as this is wrong from an
 engineering perspective, and sends a confusing message for a new function
 that is purely intended for external usage. The argument of consistency is
 IMO not strong enough to go against that pattern based on what I outlined
 above.

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