This Engineering Notebook post continues my previous ENB. Here, I'll
consider simplifying Leo's configuration code.
*Background*
Leo's configuration code is inherently complex because settings can come
from (in priority order):
- The particular .leo file,
- myLeoSettings.leo,
- leoSettings.leo,
- hard-coded defaults.
c.config.getBool, c.config.getString, etc. are the interface to Leo's
configuration code. In most respects this interface is excellent:
- The c.config methods hide all internal details.
- Unlike other python apps, Leo's classes need not be subclasses of
configuration-related classes. Similarly, there is no need for
configuration-related decorators.
So far, so good. However, many classes set ivars to "cache" configuration
settings. For example, the AtFile class contains this code:
self.checkPythonCodeOnWrite = c.config.getBool(
'check-python-code-on-write', default=True)
There are several reasons why this assignment makes sense:
1. Checking the ivar is much faster than calling c.config.getBool.
2. More importantly, the assignment is an example of the DRY (Don't Repeat
Yourself) principle. That is, it ensures that the default setting is
*always* True.
All classes that cache settings contain a *reloadSettings *method that
makes these assignments. BTW, an alternate allowable spelling is
*reload_settings*. Leo's reload-settings command calls all reloadSettings
or reload_settings methods.
*A simpler alternative?*
One could imagine "banning" such *cached settings ivars*. Instead, the
configuration machinery would cache the settings automatically. This scheme
would work as follows:
- A *settings cache* would start empty.
- For each setting x, the first call c.config.get(x) method would compute
the value, add an entry in the settings cache, and return the setting.
- Later calls to get the same setting would return the cached value.
- Leo's reload-settings command would just clear the settings cache.
This scheme would *seem* to eliminate all settings-related ivars throughout
Leo. But there are problems:
1. Only the first call to the c.config.get methods would honor the
"default" kwarg.
2. Several important settings have hard-coded "last-resort" defaults. It's
not clear how to handle those settings.
*Summary*
We could speed up the c.config.get methods using caching. This scheme might
eliminate the need for reloadSettings and reload_settings methods.
But the benefits of caching are small. The present configuration scheme is
a decent balance of generality and speed.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/leo-editor/38743826-8f9c-40a7-a47e-75f62e3a2088n%40googlegroups.com.
