Child pages
  • What's new in MPS 2.5 M1

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

You can refer to the User Guide and to the Build Language documentation for more details.

Section 3 - Improvements to the out-of-the-box languages

New XML language

A new language named jetbrains.mps.core.xml was introduced in MPS 2.5. This XML language has been designed in accordance to the XML specification. We recommend that you use this new language instead of the old ones, if you need to work with XML in MPS. All the other XML languages will be deprecated in the future.

Image Added

Anchor
refactorings
refactorings

Changes in the Refactoring language

In order to make the structure of MPS core languages more consistent and clear, the Refactoring language has been changes considerably. Several new and easy-to-use constructs have been added and parts of the functionality was deprecated and moved into the Actions language.

The UI for retrieving the refactoring parameters has been removed from the refactoring language. Choosers for parameters are no longer called, it is not allowed to show UI in init (e.g. ask and ask boolean) and keystroke has no effect. All this functionality should be moved to an action corresponding to the refactoring.

The following constructs have been added to the refactoring language. These new constructs are intended to to be used from code, typically from within the actions:

  • is applicable refactoring<Refactoring>(target)
    returns true if the refactoring target corresponds to the current target (type, single/multiple) and applicable as in refactoring isApplicable method, and there is no refactoring that overrides current refactoring for this target.
  • execute refactoring<Refactoring>(target : project, parameters );
    executes the refactoring for the target with parameters
  • create refcontext<Refactoring>(target : project, parameters )
    create a refactoring context for the refactoring, target and fill parameters in context, this context then can be used for refactoring execution or for further work with parameters; UI is not shown during this call

It is necessary to manually migrate existing user refactorings. The migration consists of several steps:

  • create a UI action for the refactoring
  • copy the caption, create context parameters
  • add a refactoring keystroke with the newly created action to KeymapChangesDeclaration
  • create ActionGroupDeclaration for the refactoring that modifies the jetbrains.mps.ide.actions.NodeRefactoring action group at the default position
  • add an isApplicable clause to the action created; usually it is just is applicable refactoring< >() call
  • add an execute clause to the action created; all the parameter preparations that were in init of the refactoring should be moved here; at the end it is necessary to execute the refactoring with the prepared parameters (with execute refactoring< >(); statement)
  • remove all parameter preparation code from init of the refactoring, they are now prepared before the entry to init; you can still validate parameters and return false if the validation fails

Customizable scopes

An element that contains a reference to some other element typically knows nothing about the scope applicable to the reference. In such cases the best solution for finding applicable elements is to forward the request upwards in the AST. By implementing the ScopeProvider interface you can intercept such requests coming from your descendants and have full control over their scopes. Since BaseLanguage itself now also follows this strategy, you can easily restrict visible elements in embedded statements or expressions.

Image Added

Textual references

The reference representation can now vary depending on the reference location, as it is in many existing textual languages. It allows languages to support the notion of qualified reference when simple name of the target element is not enough. The new API requires developers to provide the referenceText value as a part of the Scope implementation (see jetbrains.mps.scope.Scope). All references in BaseLanguage now support java-style resolving. Also, in case of broken references the referenceText serves as a hint to the developer to fix it easily.

TODO: a screen-shot ?

Custom persistence for MPS models through stubs

With the improved jetbrains.mps.lang.stubs language, which now supports write as well as read operations, it is now possible to declare a custom stubs model manager that supports model saving functionality. Using this extension point you can teach MPS how to interoperate with any custom persistence syntax. You can load and save your models from and into a format that fits your needs best. Read more at the Custom Persistence page.

Image Added

Section 4 - IDE enhancements

Dependencies analyzer

The Dependencies Analyzer can report dependencies among modules or models. It can be called from the main menu or from the popup menu of modules/models:

...

A Run Configuration, which starts another instance of MPS from MPS, can now automatically open a selected project on start. You can either choose an arbitrary project path or open the current project that is already open in the current MPS instance. In the Latter case, the project file is copied into a temporary directory to avoid collisions between the two running instances.

Section

...

New XML language

...

5

...

Image Removed

...

Changes in the Refactoring language

...

-

...

The UI for retrieving the refactoring parameters has been removed from the refactoring language. Choosers for parameters are no longer called, it is not allowed to show UI in init (e.g. ask and ask boolean) and keystroke has no effect. All this functionality should be moved to an action corresponding to the refactoring.

The following constructs have been added to the refactoring language. These new constructs are intended to to be used from code, typically from within the actions:

  • is applicable refactoring<Refactoring>(target)
    returns true if the refactoring target corresponds to the current target (type, single/multiple) and applicable as in refactoring isApplicable method, and there is no refactoring that overrides current refactoring for this target.
  • execute refactoring<Refactoring>(target : project, parameters );
    executes the refactoring for the target with parameters
  • create refcontext<Refactoring>(target : project, parameters )
    create a refactoring context for the refactoring, target and fill parameters in context, this context then can be used for refactoring execution or for further work with parameters; UI is not shown during this call

It is necessary to manually migrate existing user refactorings. The migration consists of several steps:

  • create a UI action for the refactoring
  • copy the caption, create context parameters
  • add a refactoring keystroke with the newly created action to KeymapChangesDeclaration
  • create ActionGroupDeclaration for the refactoring that modifies the jetbrains.mps.ide.actions.NodeRefactoring action group at the default position
  • add an isApplicable clause to the action created; usually it is just is applicable refactoring< >() call
  • add an execute clause to the action created; all the parameter preparations that were in init of the refactoring should be moved here; at the end it is necessary to execute the refactoring with the prepared parameters (with execute refactoring< >(); statement)
  • remove all parameter preparation code from init of the refactoring, they are now prepared before the entry to init; you can still validate parameters and return false if the validation fails

Customizable scopes

An element that contains a reference to some other element typically knows nothing about the scope applicable to the reference. In such cases the best solution for finding applicable elements is to forward the request upwards in the AST. By implementing the ScopeProvider interface you can intercept such requests coming from your descendants and have full control over their scopes. Since BaseLanguage itself now also follows this strategy, you can easily restrict visible elements in embedded statements or expressions.

Image Removed

Textual references

The reference representation can now vary depending on the reference location, as it is in many existing textual languages. It allows languages to support the notion of qualified reference when simple name of the target element is not enough. The new API requires developers to provide the referenceText value as a part of the Scope implementation (see jetbrains.mps.scope.Scope). All references in BaseLanguage now support java-style resolving. Also, in case of broken references the referenceText serves as a hint to the developer to fix it easily.

TODO: a screen-shot ?

Custom persistence for MPS models through stubs

With the improved jetbrains.mps.lang.stubs language, which now supports write as well as read operations, it is now possible to declare a custom stubs model manager that supports model saving functionality. Using this extension point you can teach MPS how to interoperate with any custom persistence syntax. You can load and save your models from and into a format that fits your needs best. Read more at the Custom Persistence page.

Image Removed

Section 5 - Other

New Productivity Guide

...