Package org.jetbrains.mps.openapi.language

Interface SAbstractConcept

  • All Superinterfaces:
    SElement, SNamedElement
    All Known Subinterfaces:
    SConcept, SInterfaceConcept
    public interface SAbstractConcept
extends SNamedElement
    A descriptor of a concept. Concepts define categories for AST nodes. The descriptor is read-only, so it is not possible to change the concept through its descriptor. SConcept (and SAbstractConcept) can be constructed using id/name pair or (better) be obtained from MetaAdapterFactory. note: the relationship between SNode and SConcept is analogical to the relationship between an object and its Class in Java

    • Method Detail

      • getName

        @NotNull
String getName()
        Description copied from interface: SNamedElement
        Presentation of the element for an end-user. Unlike identity, the name is deemed user-friendly and shall not be used for persistence.
        Specified by:
        getName in interface SNamedElement
        Returns:
        the name of the concept

      • getReferenceLinks

        Collection<SReferenceLink> getReferenceLinks()
        Returns all the references this concept has, including inherited

      • getContainmentLinks

        Collection<SContainmentLink> getContainmentLinks()
        Returns all the links this concept has, including inherited There's no "specialized links" at the compiled language level, all links are "original"

      • getProperties

        Collection<SProperty> getProperties()
        Returns all the properties this concept has, including inherited

      • isSubConceptOf

        boolean isSubConceptOf​(SAbstractConcept concept)
        Either implementing or extending the supplied concept

      • isAbstract

        boolean isAbstract()
        Returns:
        true for interfaces and abstract concepts.

      • getSuperConcept

        @Nullable
SConcept getSuperConcept()
        XXX why not BaseConcept (at least in case of concept declaration, not interface) - the only case when we care is extends of BaseConcept itself (implementation returns null in that case). Can we handle it without forcing nullable?
        Returns:
        extended concept, if present; always null for interface concept declarations, as well as for BaseConcept
        Since:
        2021.2

      • getSuperInterfaces

        @NotNull
Iterable<SInterfaceConcept> getSuperInterfaces()
        Returns directly implemented (in case of concept declaration) or extended (in case of interface concept declaration) interfaces.
        Since:
        2021.2

      • getDeclarationNode

        @Deprecated
@Nullable
SNode getDeclarationNode()
        Deprecated.
        Returns the declaration node in case sources for this concept are present in IDE Will be removed after 3.4, use getSourceNode() instead

      • getSourceNode

        @Nullable
SNodeReference getSourceNode()
        Returns reference to the node, which was generated to this concept. The target node's concept can be different form AbstractConceptDeclaration. Generally, this method should be only used for "go to concept declaration".
        Specified by:
        getSourceNode in interface SElement

      • isValid

        boolean isValid()
        Returns true if this concept is fully-functional. Typically, user code should not care about this Can return false, for example, if the containing language is absent