Earnie Boyd wrote:
Ernie, I am fine with this solution too for Drupal itself.
BUT locale module will require a list of variables and their default values defined somewhere, so we will need to do that ourselfs in this case. It seemed to be odd to do this as part of the hook_locale() introduced today, but if hook_settings() seems to be overcomplication, then we need to go that way. I thought that if
- we can save extra typing and value passing on variable_get calls - we have a hook to reuse when we need a list of variables to present for localization
adds pluses over just using constants.
Sure, only using constants for default variable values could be make variable usage better, but I think a hook do more just by being a central place and not a set of unrelated constants.
What if you used get_defined_constants() to return an associative array of constant names? You now have a key to translate the default with. We could go further and add some namespace rules to the naming of constants like DRUPAL__ for Drupal core constants and MY_MODULE__ for module specific namespace. How does this sound?
Erm, how would we know that MY_MODULE__ constants are all variable defaults? There are numerous constants in Drupal already. Look into bootstrap.inc for example: we have CACHE_, WATCHDOG_, LANGUAGE_. Or common.inc has SAVED_, file.inc has FILE_. You get the idea. Unless you especially propose the double underscore to signify "constants defined to be variable defaults", we can confuse a lot of constants with being connected to cache.module, saved.module, file.module (if these exist in the system). I don't think a naming standard helps here. As I have said, I am fine with constants, go use them! It still helps possibly multiple defaults, which is a possible place to go wrong in Drupal, and repeat unnecessary code. Gabor