GDL-Namespaces

Der GDL-Parser lässt nicht zu, dass eine Vorlage mit demselben Namen mehr als einmal definiert wird. Zwei unabhängig geschriebene Vorlagendateien können versehentlich denselben Namen für eine Vorlage verwenden und verhindern, dass Sie beide Vorlagendateien in Ihre GDL-Datei einfügen.

Um Namenskonflikte zu vermeiden, unterstützt GDL Namespaces. Der Autor einer Headerdatei kann angeben, zu welchem Namespace jede Vorlage und Makrodefinition gehören soll, indem er die gesamte Definition in ein DefineInNameSpace-Konstrukt einschließt. Das Symbol, das als instance Name dieses Konstrukts angegeben wird, wird zum Namespace, zu dem alle eingeschlossenen Definitionen gehören. Wenn sich eine Definition in zwei oder mehr geschachtelten *DefineInNameSpace-Konstrukten befindet, gehört sie nur zu dem Namespace, der durch das innerste *DefineInNameSpace-Konstrukt definiert wird. Wenn sich eine Definition nicht in *DefineInNameSpace-Konstrukten befindet, wird sie dem Standard- oder "unbenannten" Namespace zugewiesen.

Wenn Einträge, die den Text eines Vorlagen- oder Makrokonstrukts umfassen, in separate *DefineInNameSpace-Konstrukte eingeschlossen werden, platziert der Parser diese einzelnen Einträge nicht im neuen Namespace, da die einzelnen Einträge keine separate Definition sind, sodass sie nicht in einem anderen Namespace gespeichert werden können. Blockmakros ermöglichen geschachtelte Makrodefinitionen, und diese geschachtelten Definitionen können anderen Namespaces zugewiesen werden. Durch das Ändern des Namespace einer geschachtelten Definition wird die Lebensdauer jedoch nicht verlängert. Auf eine geschachtelte Makrodefinition kann nur innerhalb der Schachtelungsebene verwiesen werden, in der sie definiert wurde.

Auf einen Vorlagen- oder Makronamen kann in einer qualifizierten oder nicht qualifizierten Form in einem Namespace verwiesen werden. Um einen Vorlagen- oder Makronamen zu qualifizieren, wird dem Namen des Namespace einfach dem Vorlagen- oder Makronamen ein dazwischen liegendes Doppelpunktzeichen vorangestellt (z. B. Namespace:Makroname).

Hinweis Der Symbolname, der als Wert von *Template-, *Makros- oder *BlockMacro-Definitionen angegeben wird, kann nicht durch einen Namespace qualifiziert werden. Der Namespace einer Definition kann nur mithilfe von *DefineInNameSpace definiert werden.

Nachdem beispielsweise eine Vorlage mit dem Namen "TEMPNAME" in einem Namespace mit dem Namen "NSName" definiert wurde, kann mit einer anderen Vorlagendefinition mithilfe des namespacequalifizierten Formulars auf diese Vorlage verwiesen werden, wie im folgenden Codebeispiel gezeigt.

*DefineInNameSpace: NSName
{
    *Template:  TEMPNAME
    {
        *%  member attributes
    }
}

Auf diese Vorlage kann nun aus einer anderen Vorlage verwiesen werden, indem die namespacequalifizierte Syntax verwendet wird, wie im folgenden Codebeispiel gezeigt.

*Template:  ANOTHER_TEMPLATE
{
    *Inherits: NSName:TEMPNAME
}

Wenn die Mehrheit der Vorlagenverweise auf denselben Namespace verweist oder wenn es keine Namenskollision zwischen Vorlagennamen gibt, auf die in zwei oder mehr Namespaces verwiesen wird, können Sie den Namespacequalifizierer weglassen und nur den Vorlagennamen angeben und sich darauf verlassen, dass der Parser eine Liste von Namespaces durchsucht, bis eine übereinstimmende Vorlage gefunden wird.

Die Liste der Namespaces wird angegeben, indem ein oder mehrere GDL-Einträge in *UsingNameSpace-Konstrukte eingeschlossen werden. Wenn einer dieser Einträge nicht qualifizierte Verweise auf eine Vorlage oder ein Makro enthält, wird die Auflösung dieser Verweise durch die *UsingNameSpace-Konstrukte beeinflusst. Das Symbol, das als instance Name dieses Konstrukts angegeben wird, identifiziert den zu durchsuchenden Namespace.

Sie können mehrere Namespaces angeben, indem Sie mehrere Konstrukte verschachteln. Die Suchreihenfolge beginnt mit dem innersten *UsingNameSpace-Konstrukt und verläuft nach außen. Wenn eine Vorlagendefinition in einem angegebenen Namespace gefunden wird, wird die Suche beendet, und diese Vorlage wird verwendet. Wenn keine Übereinstimmung gefunden wurde, nachdem alle explizit angegebenen Namespaces durchsucht wurden, durchsucht der Parser den Namespace, der in jedem einschließenden *DefineInNameSpace-Konstrukt vom innersten Konstrukt nach außen benannt ist. Und wenn diese Suche den Verweis nicht auflösen kann, wird versucht, den "unbenannten" Namespace zu durchsuchen.

Hinweis Wenn Sie die Namespacesuchreihenfolge vor äußeren Einflüssen isolieren müssen, sollten alle Namespaces, die zum Auflösen von Verweisen erforderlich sind, mithilfe von *UsingNameSpace-Konstrukten angegeben werden.

Sie sollten sich nicht auf das *DefineInNameSpace-Konstrukt verlassen, um die Suchreihenfolge festzulegen, da der Host die enthaltene Datei möglicherweise mit zusätzlichen *UsingNameSpace-Konstrukten umschließt und die vom Host angegebenen Namespaces vor den Namespaces durchsucht werden, die von den *DefineInNameSpace-Konstrukten benannt werden.

In der zuvor definierten Vorlage wurden beispielsweise zwei Namespaces angezeigt, die explizit für die Vorlagennamensauflösung angegeben wurden. Jeder Namespace, der von *UsingNameSpace benannt wird, muss zuvor von *DefineInNameSpace definiert worden sein. Die Ausnahme ist der "unbenannte" Namespace, der immer vorhanden ist und durch das NULL-Symbol benannt wird.

Im folgenden Codebeispiel wird gezeigt, wie der Namespace "unbenannt" angegeben wird, um die Suchreihenfolge zu definieren.

*UsingNameSpace: NSName2
{
    *UsingNameSpace:  *%%%%%  omitting symbol specifies the  Unnamed 
*%  Namespace.
    {
        *UsingNameSpace: NSName
        {
            *Template:  ANOTHER_TEMPLATE
            {
                *Inherits: TEMPNAME
            }
        }
    }
}

Im vorherigen Beispiel wird der "unbenannte" Namespace durchsucht, nachdem alle Suchvorgänge im explizit angegebenen Namespace fehlgeschlagen sind. Im Beispiel wird jedoch explizit angegeben, dass der "unbenannte" Namespace vor dem NSName2-Namespace durchsucht wird.

Da GDL-Dateneinträge nie explizit auf Vorlagennamen verweisen, wirkt sich die Verwendung von *UsingNameSpace nicht darauf aus, welche Vorlage den einzelnen Dateneinträgen zugewiesen ist. Die Namespacesuchreihenfolge, die *UsingNameSpace angibt (die zum Zeitpunkt der Analyse des ersten GDL-Dateneintrags wirksam ist) wird jedoch bei der Suche nach der ROOT-Vorlage verwendet. Wenn Sie eine oder mehrere GDL-Headerdateien einschließen, sollten Sie sicherstellen, dass diese nicht versehentlich die erste werden, die einen Dateneintrag definiert, und somit bestimmen, welcher Namespace verwendet wird, um die ROOT-Vorlage zu finden.

Hinweis Makrodefinitionen werden durch die einschließende Schachtelungsebene eingeschränkt. Namespaceschachtelungsebenen beschränken jedoch nicht den Bereich von Makrodefinitionen, da Sie kein Makro definieren müssen, um zu einem bestimmten Namespace zu gehören, wenn der Bereich des Makros nicht groß genug ist, um außerhalb dieses Namespace sichtbar zu sein.

Namespacekonstrukte können zwischen anderen Konstrukttypen verschachtelt werden. Es gibt fast keine Einschränkung, wo ein Namespacekonstrukt angezeigt werden kann. Die Nicht-Namespacekonstrukte wirken sich nicht auf die Namespaceauflösung aus.