Das ist neu in MPS 2019.2
Enumerations-Datentyp
Neue Deklarationen für Enumerationsdatentypen bieten eine übersichtliche Möglichkeit, eine Liste von Optionen zu deklarieren: Jede Option wird mit einem benannten Enumerations-Member ausgedrückt. Optional ist es möglich, die Darstellung des Editors für manche Member zu ändern und das Standardelement auszuwählen, das verwendet wird, wenn in einer Eigenschaft kein Member explizit festgelegt ist.
Individualisierung von Fehlermeldungen Von Kunden gewünscht
Seit einiger Zeit gab es Anfragen nach der Möglichkeit, manche MPS-Fehlermeldungen zu individualisieren. Dank einer Anfrage von einem unserer zahlenden Kunden konnten wir diesem Feature höchste Priorität zuweisen. Jetzt können alle Einschränkungen der Fehlerberichterstattung geändert werden. Wir planen, diese Individualisierung von Berichten für andere Arten von Fehlern in den nächsten Versionen verfügbar zu machen.
Für die Individualisierung von Fehlertexten steht ein neuer Aspekt mit dem Namen „feedback“ zur Verfügung.
Regelbasierte Einschränkungssprache
Die regelbasierte Einschränkungssprache wurde erstellt, um die derzeit verfügbare canBe*-Einschränkung der regulären MPS-Einschränkungssprache in Zukunft zu ersetzen. Wir betrachten die regelbasierte Einschränkungssprache als experimentelle Funktionalität und gehen davon aus, dass sie sich in den nächsten Versionen erheblich weiterentwickeln wird.
Root-Verlauf
Das Git-Menü enthält eine neue Aktion, mit welcher der Verlauf von VCS-Änderungen eines bestimmten Stammverzeichnisses angezeigt wird. Die Aktion ist über das Kontextmenü des Editors verfügbar.
Volltextsuche
Die Volltextsuche in den Eigenschaftswerten ist fertig. Die Aktion „Edit–>Find–>Find Text in Project“ (Strg+Alt+Umschalt+F) ermöglicht Ihnen, Knoten mit Eigenschaftswerten zu finden, die dem angegebenen Text entsprechen.
Spezifische Fehlerprüfung
Einer der häufigsten Anwendungsfälle einer Testsprache besteht darin, Knoten auf Fehlermeldungen oder Warnungen zu überprüfen. Das Test-Teilsystem von MPS konnte manchmal nicht zwischen verschiedenen Fehlern unterscheiden, die auf demselben Knoten auftraten. Dies konnte zu irreführendem Verhalten führen: Selbst wenn der Benutzer den erwarteten Fehler in der entsprechenden Test-Annotation angab, wurden zusätzliche Fehler und Warnungen, die auf diesem Knoten gemeldet werden, nicht als Testverstöße gemeldet.
Prüfregeln für Muster definiert
Beim Definieren einer Checking Rule [Prüfregel] für ein Konzept wird die Regel später für jeden Knoten aufgerufen, der eine Instanz des Konzepts ist.
Anstatt nun eine vom Oberkonzept geerbte Regel zu überschreiben, kann die Liste der zu überschreibenden Regeln explizit angegeben werden. Wir empfehlen dringend, alle Ihre Prüfregeln zu überprüfen, die auf die Überschreibungsfunktion zurückgreifen, und festzulegen, welche Regeln überschrieben werden sollen.
Typprüfende Facade-API
Ab dieser Version ist die neue Facade-API die einzige unterstützte Weise, typprüfende Abfragen auszuführen.
Neue API: Siehe jetbrains.mps.typechecking.TypecheckingFacade und zugehörige Klassen.
Veraltete API (Legacy): Die Hierarchie der Pakete jetbrains.mps.typesystem.* ist jetzt veraltet. Von jeglicher direkter Verwendung von Klassen innerhalb dieser Hierarchie wird abgeraten, mit Ausnahme von Code, der automatisch aus dem Inhalt eines „typesystem“-Aspekts generiert wurde.
Änderungen in den kommenden Versionen
Das Folgende ist ein vorläufiger Plan von Änderungen, die in Bezug auf die Typsystem-Unterstützung vorgenommen werden. Der Aspekt, der für die Implementierung des Typsystems verantwortlich war, sowie die in diesem Aspekt verwendete Sprache werden als veraltet (legacy) gekennzeichnet. Mit der Zeit werden die Sprache und die Laufzeitunterstützung in ein separates Plugin migriert.
Es wird ein neuer Aspekt eingeführt, der im Wesentlichen den "Nicht-Typsystem"-Teil des Typsystem-Aspekts ersetzt. Es wird eine Migration bereitgestellt, um Prüfregeln aus dem alten Typsystem-Aspekt zu extrahieren.
Es werden ein neues Typprüfungs-Framework und eine Laufzeitunterstützung eingeführt. Dies bedingt ein vollständiges Umschreiben der Legacy-Engine.
Make im Hintergrund
Make-Prozesse im Hintergrund funktionieren ordnungsgemäß. Wir haben daran gearbeitet, die Reaktionsfähigkeit der Benutzeroberfläche zu verbessern, während ein Make im Hintergrund ausgeführt wird. Wenn Sie die vorherige Version wiederherstellen möchten, gibt es dafür eine neue Benutzeroberflächen-Einstellung, mit der Sie all dies steuern können: Preferences–>Project Settings–>Perform in background.
Java 11 als Runtime
MPS wird jetzt unter JDK 11 ausgeführt. Dies wirkt sich auf den Lademechanismus von Stub-Modellen aus. Die meisten Projekte brauchen nicht migriert zu werden, mit Ausnahme der seltenen Verwendung mancher Klassen und Felder, die in der JDK 11 neu paketiert wurden.
Im IntelliJ-IDEA-Plugin sollten jetzt die Module mit MPS-Facette mit der JDK-Version 11 verknüpft werden. Andernfalls schlägt die Codegenerierung fehl.
BaseLanguage
BaseLanguage-Verbesserungen waren eines der Hauptziele für diese Version. Wir haben viele Probleme im Zusammenhang mit BaseLanguages behoben, von Fehlern bis hin zu Problemen mit der Benutzerfreundlichkeit.
Neues Beispielprojekt
Auf Grundlage des Feedbacks der Community haben wir ein neues Beispielprojekt für die XML-Generierung hinzugefügt.
Rechtschreibprüfung in BL-Kommentaren
Wir haben eine Rechtschreibprüfung für einzeilige Kommentare, Javadoc-Text und Stringliterale bereitgestellt.
Lokale Git-Konfiguration
Wir haben die Einstellungen für die Merge-Treiber von global auf lokal geändert (pro Git-Repository), so dass jetzt ebenso viele Merge-Treiber wie MPS-Installationen möglich sind.