Warum verwenden so viele Programme die Stilkonfigurationen "foo.bar.baz = qux"?

497
cpast

Ich habe festgestellt, dass Tonnen von Programmen Konfigurationsinformationen in verschiedenen hierarchischen Schlüsseln speichern. Zum Beispiel hat Firefox about:configSchlüssel wie network.http.pipeliningund network.http.pipelining.sslund network.http.use-cache. Ich habe diese Art der Konfiguration in Firefox, in OS X ( Library/Preferences) sysctl, unter anderem festgestellt . Warum ist es so häufig? Gab es ein früheres Programm, das es verwendete, also haben andere es kopiert?

3
Wenn etwas zu kompliziert ist, um effektiv gehandhabt zu werden, unterteilen Sie es in eine Hierarchie mit kleineren, überschaubareren Komponenten ... Mehrdad vor 11 Jahren 0
Ich habe die Frage wieder geöffnet. Es ist nicht "nicht konstruktiv", wie die sehr informativen Antworten zeigen. slhck vor 11 Jahren 0

2 Antworten auf die Frage

5
mtone

Diese hierarchische Konvention dient der Klarheit und hilft uns, den Einflussbereich der einzelnen Einstellungen zu kennen und mehrere Einstellungen mit identischem oder mehrdeutigem Namen zwischen verschiedenen Modulen zu unterscheiden.

Dies ist nützlich in Anwendungen mit zu vielen möglichen Einstellungen, um sie in die Hauptbenutzeroptionsseiten aufzunehmen (auf denen die Hierarchie durch Registerkarten oder Seiten angezeigt wird). Dies ist eine gute Alternative zu einfachen INI-Dateien (mit [title]Abschnittsbegrenzern), die anfälliger für Benutzerfehler sind und erfordern in der Regel einen Neustart der Anwendung, um wirksam zu werden.

Hierarchische Einstellungen spiegeln wahrscheinlich auch das interne objektorientierte Top-Down -Modell wider, das von den Entwicklern verwendet wird:

Bild der Hierarchie

In diesem Beispielmodell können wir uns sehr gut vorstellen, dass dort eine person.professor.disallow_strikes = true -Einstellung vorhanden ist, während ein students.disallow_strikes auf false stehen kann oder überhaupt nicht verfügbar ist. Diese Unterteilung ist auch die Grundlage für Namespaces in Programmiersprachen (und das gängige .NET-Framework folgt genau derselben Namenskonvention:) using System.Threading.Tasks.

Wir können also jetzt davon ausgehen, dass die network.http.xxxEinstellung keinen Einfluss auf network.ftpoder auf andere Netzwerk-Submodule haben sollte, während eine network.xxxEinstellung wahrscheinlich alle beeinflusst.

Die zusätzlichen Informationen sind von Vorteil ...

  • für den Benutzer: Wir haben eine bessere Vorstellung davon, auf welchen Teil der Anwendung eine bestimmte Einstellung Einfluss hat, wodurch Probleme leichter zu beheben sind (und vermieden werden können).

  • und für die Entwickler: Die Person, die an einem bestimmten Modul arbeitet oder Fehlerbehebungen vornimmt, kann leicht erkennen, welche vom Benutzer veränderbaren Einstellungen die aktuelle Arbeit beeinflussen und sich darauf konzentrieren können.

4
SuperMagic

Sie haben in Ihrem Eröffnungssatz einen der Hauptgründe erwähnt: hierarchische Schlüssel.

Jede Gruppe von Schlüsseln ist gruppiert. Alle netzwerkbezogenen Schlüssel sind netzwerk.etwas. Alle http-bezogenen Schlüssel sind network.http.something und so weiter. Dies macht den Schlüssel selbst etwas selbstdokumentierend, worauf sich der Wert bezieht. Wenn Sie den ini-Dateistil verwenden würden (was klar ist, nichts würde Sie daran hindern, diese Art von Schlüsseln zu verwenden, wenn Sie dies wollten) mit [section] und key = value-Paaren, kann ein bestimmter Schlüssel bis zum betreffenden Abschnitt mehrdeutig sein bekannt. Darüber hinaus ist die Platzierung von Schlüsseln in einer Datei wichtig. Das Einfügen des SSL-Schlüssels in den Abschnitt [GUI] ist wahrscheinlich ein Fehler und kann dazu führen, dass der Schlüssel ignoriert wird. Der abc-Stil sollte bedeuten, dass die Reihenfolge der Schlüssel in einer Datei keine Rolle spielt. Wenn Sie networking.http.ssl.key = lesen, spielt es keine Rolle, ob die vorherige Zeile gui.background.color = oder etwas anderes war. Der vollständig qualifizierte Schlüssel wird benannt.

Warum ist es so häufig? Es ist verdammt nützlich, deshalb. Es ist auch für Menschen einfach zu lesen und zu verstehen (Schlüssel für Schlüssel) und zu bearbeiten.

Woher kam das? Ich würde sagen, C-Strukturen, die wahrscheinlich eine Abstammung haben, von der ich keine Kenntnis habe, und die auch in viele andere Programmiersprachen übergegangen sind. Das Festlegen eines Werts in einer C-Struktur wäre structure.property = value und für geschachtelte Strukturen struct.substructure.property = value usw. (obwohl Zeiger im wirklichen Leben viele dieser Punkte in -> konvertieren würden, ist dies jedoch ein kleine Kleinigkeit).

Es ist auch wie bei * Namespaces *, die Implikation lautet "." dient als semantisches Trennzeichen. mr.spuratic vor 11 Jahren 3
Noch besser. Was Mr. Spuratic gesagt hat. SuperMagic vor 11 Jahren 0