[development] low hanging fruit for Drupal 6: variable defaults

[Gabor Hojtsy]

Earnie Boyd wrote:
>> There are times one might try to access a variable defined by another 
>> module, such as variable_get('site_name', 'Drupal'); This would make 
>> it easier to avoid having to remember later if that's supposed to be 
>> variable_get('site_name', 'drupal'), variable_get('site_name', 
>> t('Drupal')), variable_get('site_name', SYSTEM_SITE_NAME_DEFAULT), or 
>> whatever. I believe just calling variable_get('site_name') would 
>> certainly makes things more standard, and easier to maintain.
> 
> And how do you know that 'site_name' is a variable to get?  What happens 
> when I variable_get('not_a_saved_variable')?  If the variable is public 
> then it needs to be documented so you would know how to get it and you 
> would know how to supply it's default value.
> 
> With what is being proposed variable_get would need to try to get the 
> default value of the variable every time.  Now it is given so that it 
> doesn't have to try to guess.  Why do I need variable_get to try to 
> waste resources by trying to guess the default when I can give it along 
> with the variable?  This wasted resource is system wide and affects 
> every module that stores a variable.

Earnie, what is being proposed, is to have a hook to define variable 
defaults. It was not proposed to have this hook get called *on every 
variable_get() call*, which you seem to imply with "try to get the 
default value of the variable every time". Now variable_get() works this 
way:

  -> try to get the variable cache from cache_get()
     -> no cache, select * from variables and save to the cache table

  -> now we have an associative list of saved variable values

  -> look up variable name requested
     -> found, return the value
     -> not found, return the passed $default

With a hook returning variable default values, we can do a whole lot of 
different things:

  (a) save the defaults to the variables table, so you get them
      cached later
  (b) retrieve the defaults when refreshing the variable cache,
      and save the defaults to the cache with the variables
  (c) call the hook every time variable_get is called

It seems you imply (c), which is admittedly the least performant 
solution. I would imply (a) or (b), I really don't care either. An 
example flow with option (b):

  -> try to get the variable cache from cache_get()
     -> no cache, select * from variables *AND* module_invoke_all
        the variables default hook and save to the cache table

  -> now we have an associative list of saved variable values

  -> look up variable name requested
     -> found, return the value
     -> not found, return empty string / NULL / FALSE whatever is decided

The performance implication of this move is that the variable cache will 
have more values cached then before. The difference varies depending on 
how many settings screens did you hit your submit buttons on before. If 
you have most of your variables saved into the variables table anyway 
(you submitted most of your settings forms at least once), the 
difference is negligible.

The gain is however that you don't need to specify the default value 
every time (the *developer* don't need to guess the default value on all 
variable_get() calls), and as a result, this default value will not get 
passed every time you call variable_get. It will only be in it's local 
variable value cache, which only ever changes if you submit a settings form.

Gabor