wiki:Meetings/Meet-2009-07-31

KIELER Meeting 2009-06-05

  • Moderator: haf, rvh,
  • Protocol: cmot

Topics

  • State
  • Schlüsselwort state
  • Lesbarkeit / Konvention
  • Namensräume / Regions
  • Schlüsselwort Suspend
  • Umbenennungen

State

  • Eigentliche Idee: Boolean Flags für Dinge die sich nicht gegenseitig ausschließen
  • Aber: Sprache sollte möglichst einfach zu erklären sein
  • Attribute nicht in unterschiedlichen Kategorien
  • Frustrationsgrad des Anwenders sollte gering gehalten werden
  • Reihenfolge wie in Java: zunächst alle Modifier, dann Typ, dann Name
  • Modifyer: init final reference
  • Alles sind Modifyer

Schlüsselwort state optinal?

  • JA, aber nicht ganz darauf verzichten
  • Schwierigkeiten wenn alles optional ohne Semikolon => Mehrdeutigkeit
  • Oder: Unterscheidung, nur optional wenn Eindeutigkeit gegeben ist
  • init <BR> A bedeutet A ist ein initial Zustand
  • A <BR> { ... } bedeutet { ... } gehört zum Zustand A
  • Schlüsselwort erstmal optinal machen, evtl später auch ganz darauf verzichten
  • Für VL z.B. für das ungeübte Auge besser MIT Schlüsselwort state lesbar
  • Parsen: "möglichst viel" (vgl. C)

Lesbarkeit

  • Ende von Blöcken durch Kommentare erkennbar machen
  • onentry usw sinnvollerweise an den Anfang (per Konvention)

Eindeutigkeit von Namen/Namensräume/Regions?

  • Interleveltransitionen von einem in einen anderen Macrostate
    • Kompletter qualifizierter Ausdruck: -> Chart.M2.A, A -> Chart.M2.A,
    • Oder: Relativ wie in Verzeichnissen A -> ...M2.A
      • Vorteil: Einfügen von Macrostates aus anderen Diagrammen, nicht alle Pfade ändern müssen
      • Punkte am Anfang: eine Hierarchiestufe pro Punkt nach oben
  • In grafischer GMF Variante sind Regions eigenständige Objekte
  • Nicht als Teil der Sprache, nur als Werkzeugunterstützung z.B. optionale Anzeige der Region-Nummer
  • Bei code-Generierung: Kommentare automatisch generieren Region_0
  • Automatisch durchnummerieren
  • Nicht die Sprache erweitern, d.h. nicht das Metamodell erweitern
  • Problem bei automatische Serializierung durch Xtext, allerdings durch Reihenfolge durchgegeben (selbst implementierte "formater" generieren nicht nur Whitespace sondern auch solche Kommentare)
  • Aus Entwicklersicht: Zwingend unterschiedliche Namen in unterschiedlichen Regionen sind eher "lästig" (-> DECOS)
  • Nach Diskussion:
    • Nicht nur gleiche State-Namen sondern auch gleiche Variablen-Namen
    • Region bekommt einen Namen
    • Sprache enstprechend erweitern
    • Enstprechung zu And-Or-Trees (Knoten haben auch immer Namen!)
    • Regions als echte States, Parallel-Operator zeigt nächste Region an => mehr {} für mehr Hierarchiestufen
    • Region-Namen nur wenn Referenzierbarkeit nötig, dann zwingend
    • Variablen-Deklarationen auf Region-Ebene möglich
    • Per Default: dem State zuordenen, wenn Region explizit, dann der Region zuordnen
    • Für jede Region gibt es einen anonymen Zustand

Suspend

  • Echtes Schlüsselwort für suspend

Signal Renaming

  • Möglichst ähnlich wie E-Studio