I'm wondering if we're disconnected a little on how it would be implemented. In your example after this you used Zend_Config::CONFIG_LIFETIME. In my example I used Zend_Cache_Core::CONFIG_LIFETIME which would equal "lifetime", the configuration option for that class. The "logging" configuration option would be Zend_Cache_Core::CONFIG_LOGGING. The values of constant would map back to the option value directly, except that configuration constants would be pre-pended with CONFIG_.
Is that what you were thinking as well or were you thinking of putting everything in Zend_Config? Kevin > By not having the constant value corresponding to the constant name, > it's more difficult to guess what the key should be called. And what if > there are constants that use the same suffix -- e.g. CORE_LIFETIME; how > do you refer to that? > > With configuration options, you cannot assume that the only place you > will be referencing them is in PHP code, and hence, IDEs -- people may > be building config files, and will need to know the keys. If they are > not easily predictable from the constant names, they're going to have > the same problems you outlined already. > > For instance, I use VIM, and utilize ctags extensively, which gives me > tab completion for most PHP datatypes -- classes, methods, constants, > class members, etc. I might be able to find the constant name easily > with tab completion, which would then let me write my config file. So, I > might receive Zend_Config::CONFIG_LIFETIME from completion; the question > is, how do I then translate that to a config key? My initial guesses > would be either 'CONFIG_LIFETIME' or 'configLifetime' -- but I'd never > expect it to be simply 'lifetime'. > > So, the change I'm suggesting is two-fold: > > * Adding the constants > * Standardizing the relationship between constant names and values > > That way I don't even have to guess -- I know *exactly* what the config > key would then be, based on the constants available. >
