Vorschlag: Advanced Object Notation

libSonParser ist eine freie Open-Source C++-Library zum Parsen von SON-Dateien, welche einen vereinfachten JSON-Syntax darstellen. Projektwebsite bei bitbucket.
Benutzeravatar
NeoArmageddon
Beiträge: 1165
Registriert: 13.02.2012 20:34
Wohnort: Göttingen
Kontaktdaten:

Vorschlag: Advanced Object Notation

Beitragvon NeoArmageddon » 01.09.2016 15:08

Für ein Projekt habe ich ein leicht zu schreibendes Config Format gesucht, natürlich lag es nahe, Glatzemanns libSon zu verwenden. Das JSON Format ist weit verbreitet und mit Glatzes Verbesserungen zu Son sogar noch einfacher zu verwenden.

Nach ein paar Tests haben sich allerdings ein paar Probleme mit dem libSonParser und dem Format selbst herausgestellt
  • Einige Elemente sind nicht eindeutig definiert. So kann ein KeyValue Eintrag teil eines Arrays sein, was denselben nahezu äquivalent zu einem Objekt macht.
  • Objekte sind nicht die grundlegende Einheit des Formats.
  • Viel Redundanz durch Value/KeyValue, Object und NamedObject, etc
  • Objekte können nicht Element eines KeyValue paars sein.
  • Alle Werte werden als String gespeichert und bei Bedarf in andere Formate konvertiert.

Da SON nicht ganz meinen Anforderungen gerecht wird, hab ich auf Basis des Formates und Glatzes Parser ein eigenes Format entwickelt, welche ich hier erstmal "Advanced Object Notation" oder kurz "AON" nennen möchte. Ich möchte euch das Format hier kurz vorstellen (und wo der Unterschied zu SON liegt):

  • Elementarer Strukturtyp des Formates sind Objekte und Arrays.
  • Objekte bestehen ausschließlich aus Key-Value-Paaren. Arrays ausschließlich aus Werten (im libSonParser war das etwas aufgeweicht).
  • Anführungszeichen um Keys und Werten sind optional solange keine Leerzeichen oder reservierte Symbole enthalten sind.
  • Alle Schlüssel sind Strings.
  • Alle Werte sind zunächst Strings (Kompatibilität zu SON).
  • Werte können mit einem Typenbezeichner explizit als Integer(int),Float(flt),Double(dbl) oder Boolean(bool) gekennzeichnet werden. Der Parser konvertiert diese Werte beim einlesen bereits und hält sie in diesem Format vor.
  • Konvertierung zwischen den meisten Typen ist weiterhin möglich.
  • Schlüssel in Objekten müssen einzigartig sein.
  • Ein Objekt kann per speziellem Bezeichner als abgeleitetes Objekt gekennzeichnet werden. Alle Schlüssel/Werte des Parents werden kopiert. Schlüssel im Child die bereits im Parent existieren werden vom Child übernommen.

SON ist super für einfache Konfigurationsdateien aber das Steuern von Data-Driven Engines wird damit sehr mühsählig. AON soll hier Abhilfe schaffen. Dazu ein Beispiel einer einfachen Konfig wie ich sie momentan für eine Engine nutze:

Code: Alles auswählen

//Basic defines for the engine creation
"cfgEngine" : {
   "window_width" : 800
   "window_height" : 600
}
//Fonts used by UI
"cfgFonts" : {
   "Verdana" : "./verdana.ttf"
   "Arial" : "./arial.ttf"
}

/*
The following two objects are global prototype definition.
Other objects can inherite their values by globalspace identifier @ and their name.
*/

//Basic text font and color
"BasicText" : {
   "type" : "text"
   "color" : [(flt)1.0,(flt)1.0,(flt)1.0]
   "font" : "Verdana"
}
//Definition of a blue fullscreen box
"FullscreenBackground" : {
   "type" : "box"
   "color" : [(flt)0.0,(flt)0.0,(flt)1.0]
   "size" : [(flt)1.0,(flt)1.0]
}

//Screens are collections of GUI elements that are created together
"cfgScreens" : {
   "Intro" : {
      "elements" : [
         <@FullscreenBackground>{} //The blue Fullscreen background
         <@BasicText>{
            "text" : "Welcome"
            "position": [
               (flt)0.5
               (flt)0.5
            ]
         }
         { //This object doesn't inherite from BasicText and needs to define everything itself
            "type" : "text"
            "text" : "Press any key"
            "color" : [(flt)1.0,(flt)1.0,(flt)1.0]
            "font" : "Verdana"
            "position": [
               (flt)0.5
               (flt)0.75
            ]
         }
      ]
   }
   "Main" : {
      "elements" : [
         <@FullscreenBackground>{ //background with overwritten color
            "color" : [(flt)1.0,(flt)0.0,(flt)0.0]
         }
         <@BasicText>{
            "text" : "Main Menu"
            "font" : "Arial"
            "position": [
               (flt)0.5
               (flt)0.5
            ]
         }
      ]
   }
}

//Some entities that can be created by script
"cfgEntities" : {
   "Player" : {
      "model" : "player.obj"
      "health" : (int)100
   }
   "Monster" : {
      "model" : "monster.obj"
      "health" : (int)100
      "size" : (flt)1.0
   }
   "Boss" : <Monster> {
      "health" : (int)200
      "size" : (flt)2.0
   }
}


Was haltet ihr davon?

Benutzeravatar
Glatzemann
Administrator
Beiträge: 3230
Registriert: 08.02.2012 13:35
Wohnort: Leverkusen
Kontaktdaten:

Re: Vorschlag: Advanced Object Notation

Beitragvon Glatzemann » 01.09.2016 15:49

Ich finde die Idee an sich ganz gut...

Und jetzt meckere ich :-)

Nein... Nicht wirklich. Ich verstehe deinen Hintergrund, aber genau das wollte ich eben nicht mit SON machen. Den großen Vorteil bei JSON sehe ich darin, daß man im Grunde eine JavaScript-Objekt serialisieren und deserialisieren kann. Als nachteilig habe ich empfunden, daß man teilweise recht viel tippen muss und teilweise der Syntax etwas kompliziert ist. Das wollte ich mit SON "lösen". Also etwas andere Zielsetzung als bei AON.

Benutzeravatar
NeoArmageddon
Beiträge: 1165
Registriert: 13.02.2012 20:34
Wohnort: Göttingen
Kontaktdaten:

Re: Vorschlag: Advanced Object Notation

Beitragvon NeoArmageddon » 01.09.2016 16:24

Glatzemann hat geschrieben:Nein... Nicht wirklich. Ich verstehe deinen Hintergrund, aber genau das wollte ich eben nicht mit SON machen. Den großen Vorteil bei JSON sehe ich darin, daß man im Grunde eine JavaScript-Objekt serialisieren und deserialisieren kann. Als nachteilig habe ich empfunden, daß man teilweise recht viel tippen muss und teilweise der Syntax etwas kompliziert ist. Das wollte ich mit SON "lösen". Also etwas andere Zielsetzung als bei AON.


Und genau darum ist AON nicht mehr "Simple" ;)

Hab gerade übrigens den Parser noch so umgeschrieben, dass er nun nicht die Position eines Fehlers, sondern die Zeile ausgibt. Finde ich wesentlich hilfreicher beim Debuggen ;)

Benutzeravatar
Glatzemann
Administrator
Beiträge: 3230
Registriert: 08.02.2012 13:35
Wohnort: Leverkusen
Kontaktdaten:

Re: Vorschlag: Advanced Object Notation

Beitragvon Glatzemann » 03.09.2016 09:09

Das mit der Zeile schreit ja geradezu nach einem Backport ;)

Benutzeravatar
NeoArmageddon
Beiträge: 1165
Registriert: 13.02.2012 20:34
Wohnort: Göttingen
Kontaktdaten:

Re: Vorschlag: Advanced Object Notation

Beitragvon NeoArmageddon » 03.09.2016 11:09

Hab nun auch einen Bug gefixt, der verhindert, das das letzte Zeichen in einem Array nicht als Teil eines Tokens erkannt wird ;)


Zurück zu „libSonParser“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast