Package jetbrains.mps.smodel

Class SLanguageHierarchy

java.lang.Object

jetbrains.mps.smodel.SLanguageHierarchy

public class SLanguageHierarchy
extends Object

Build a closure of extended or extending languages for a given set of language. Likely, shall be part of openapi/smodel, but as long as it needs LanguageRegistry to access runtimes, lives in kernel. XXX Though might be reasonable to introduce interface for LanguageRegistry and LanguageRuntime? IMPORTANT: This class is intended for code that cares about actual runtime state. Generally, a language module may declare a dependency which is not satisfied and therefore runtime counterpart for the module will miss this dependency. This is unlikely to happen now as classloading is quite strict about module dependencies, and we still use source module (with all the source-level dependencies), so that Lang1 that aggregates Lang2 would require Lang2 to be present at classloading time and therefore RT information would be complete. Nevertheless, it's wise to keep the possible distinction between declared and runtime dependencies in mind.

Nested Class Summary

Nested Classes

Modifier and Type	Class	Description
static interface	SLanguageHierarchy.ErrorHandler

Constructor Summary

Constructors

Constructor	Description
SLanguageHierarchy(Collection<SLanguage> languages)	Deprecated.
SLanguageHierarchy(LanguageRegistry languageRegistry, Collection<SLanguage> languages)

Method Summary

Modifier and Type	Method	Description
Set<SLanguage>	getAggregated()	Language could re-use concepts of another language either by reference or by aggregation, with special meaning for 'extends' reference.
Set<SLanguage>	getExtended()	Closure of extended languages according to runtime state.
Set<SLanguage>	getExtendedLangs(SLanguageHierarchy.ErrorHandler handler)
Set<SLanguage>	getExtending()
Collection<SLanguage>	getInitial()

Methods inherited from class java.lang.Object

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

Constructor Detail

SLanguageHierarchy

public SLanguageHierarchy(@NotNull
                          LanguageRegistry languageRegistry,
                          @NotNull
                          Collection<SLanguage> languages)

SLanguageHierarchy

@Deprecated
public SLanguageHierarchy(@NotNull
                          Collection<SLanguage> languages)

Deprecated.

Method Detail

getInitial

public Collection<SLanguage> getInitial()

getExtended

@NotNull
public Set<SLanguage> getExtended()

Closure of extended languages according to runtime state. If some language is not present just a warning is posted. Note, we don't look into dependencies recorded along with module, here, we stick to runtime state (which may be missing some languages specified in dependencies).

Returns:

Inclusive set of languages extended by those from initial set.

getExtendedLangs

@NotNull
public Set<SLanguage> getExtendedLangs(@NotNull
                                       SLanguageHierarchy.ErrorHandler handler)

getExtending

public Set<SLanguage> getExtending()

Returns:

Inclusive set of languages that extend those from initial set

getAggregated

public Set<SLanguage> getAggregated()

Language could re-use concepts of another language either by reference or by aggregation, with special meaning for 'extends' reference. 'Extends' has a long history and is even projected into module dependencies, however, we shall not forget about re-use by aggregation, which has not been exposed in module dependencies and therefore required various tricks in user scenarios to ensure aggregated languages are visible (most prominent is use of devkits).

Aggregation means concept has aggregation link with target from another language. Here, we collect direct, one-level dependencies only, i.e. we don't look into languages extended/aggregated by those we collect here. There's no solid reason not to collect aggregated with extended, just need a justification to do this extra effort. At the moment, it seems that it's sufficient to use directly mentioned language only, although this way intentions and editor transformation menus, declared in in base language, might be missing (LangA aggregates concept B from LangB that extends concept C of LangC; LangC declares transform menu and intentions for C). It looks like the decision whether to respect extended languages of those aggregated has to be made by calling code.

Returns:

Inclusive set of languages that are aggregated by languages from initial set.