Last modified 3 years ago
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