Package jetbrains.mps.smodel

Class ModelDependencyResolver

java.lang.Object

jetbrains.mps.smodel.ModelDependencyResolver

public final class ModelDependencyResolver
extends Object

Resolves imports of a model with respect to supplied context. Knows peculiarities about implicitly imported models like accessory models of used languages. This class doesn't deal with model access as it assumes you've got one prior to obtaining SModel instance OOP counterpart of ModelDependencyUpdate and ModelDependencyScanner to replace SModelOperations static methods.

XXX Perhaps, might get an optional argument to pipe resolve failures to

Since:

2018.3

Constructor Summary

Constructors

Constructor	Description
ModelDependencyResolver(LanguageRegistry languageRegistry, SRepository repository)	FIXME split MDR into two, usedLanguages has to depend from LanguageRegistry only (resolve devkits through LR, not repo)

Method Summary

Modifier and Type	Method	Description
Collection<SModel>	directImports(SModel model)
Collection<SModel>	implicitImports(SModel model)
Collection<SLanguage>	usedLanguages(SModel model)

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

ModelDependencyResolver

public ModelDependencyResolver(@NotNull
                               LanguageRegistry languageRegistry,
                               @NotNull
                               SRepository repository)

FIXME split MDR into two, usedLanguages has to depend from LanguageRegistry only (resolve devkits through LR, not repo)

Parameters:

languageRegistry - registry to resolve used languages in

repository - where to look imported models up. Generally, just a model.getRepository() and could have been omitted, MPS now asks for *resolved* imports of a detached model (e.g. during m2m phase and therefore we can not rely on model's repository, hence need to supply one explicitly. The proper fix is to ensure a model is always inside a repository, even during m2m phase. FIXME besides, we need to resolve devkit references to find out used languages, and as long as LR keeps RT presentation for lanuages only (not solutions nor devkits), we still rely on a repository to find out this essentially RT information

Method Detail

directImports

public Collection<SModel> directImports(@NotNull
                                        SModel model)

Returns:

models explicitly listed as imported in the model, excluding the model itself. Imports unresolved in the supplied repository are ignored.

implicitImports

public Collection<SModel> implicitImports(@NotNull
                                          SModel model)

Returns:

models available through used languages. If by any chance model uses a language it's accessory to, it's not reported as such.

usedLanguages

public Collection<SLanguage> usedLanguages(@NotNull
                                           SModel model)

Returns:

languages both listed directly as used, and available through employed devkits, including extended devkits but not languages (use SLanguageHierarchy to build complete set. Values are unique. XXX I am not sure this approach to build up a set of 'used' languages is 100% right, e.g. why do we respect extended devkits but not extended languages. Just kept the logic the way it was for years.