This hierarchical convention is there to provide clarity, helping us to know the scope of influence of each settings and to differentiate multiple settings with an identical or ambiguous name among various modules.
This is useful in applications with too many possible settings to include in the main user option pages (where the hierarchy is shown by tabs or pages), and a good alternative to plain INI files (with [title]
section delimiters) that are more prone to user error and usually require an application restart to take effect.
Hierarchal settings are also likely to reflect, to an extent, the internal top-down object-oriented model used by the developers:
In this example model, we could very well imagine a person.professor.disallow_strikes = true setting in there, while a students.disallow_strikes could remain to false or not be available at all. This compartmentalization is also the basis for Namespaces in programming languages (and the popular .NET framework follow the exact same naming convention: using System.Threading.Tasks
).
So, we now can assume that network.http.xxx
setting should not have influence on network.ftp
or other network submodules, while a network.xxx
setting will likely have influence on all of them.
The extra information is beneficial...
for the user: we have a better idea of which part of the application a given setting will have influence, making problems easier to troubleshoot (and avoid!)
and for the developers: the person working on or troubleshooting a specific module can be easily aware of which user-modifiable setting can affect his/her current work and concentrate on that.