There is a lot of code right now that references a Perspectives.root_prefs object and uses it to get or set preferences. In several places we have extra checks to make sure the root_prefs object is not null before taking any action.
This is not clean code because the caller has to worry about the internal state of preference initialization and how preferences work. The caller shouldn't have to worry about internal state. The system that deals with getting or setting preferences should handle its own state and wrap/hide it, so callers don't need to worry.
Included in the 4.6.4 release I have added wrapper functions so you can call e.g. Perspectives.getBoolPref() and simply get or set a preference. This hides the interface so callers don't have to worry about what's happening behind the scenes.
After the 4.6.4 release is out we should go through the code and clean up all of these uses, to avoid having each caller track internal state.
This would also help pave the way towards isolating all browser-specfic functionality behind an interface, so it can be easily implemented and swapped (i.e. so we can port Perspectives to another browser).
There is a lot of code right now that references a
Perspectives.root_prefs
object and uses it to get or set preferences. In several places we have extra checks to make sure theroot_prefs
object is not null before taking any action.This is not clean code because the caller has to worry about the internal state of preference initialization and how preferences work. The caller shouldn't have to worry about internal state. The system that deals with getting or setting preferences should handle its own state and wrap/hide it, so callers don't need to worry.
Included in the 4.6.4 release I have added wrapper functions so you can call e.g.
Perspectives.getBoolPref()
and simply get or set a preference. This hides the interface so callers don't have to worry about what's happening behind the scenes.After the 4.6.4 release is out we should go through the code and clean up all of these uses, to avoid having each caller track internal state.
This would also help pave the way towards isolating all browser-specfic functionality behind an interface, so it can be easily implemented and swapped (i.e. so we can port Perspectives to another browser).