Spielraum (Informatik)

In der Computerprogrammierung ist ein Spielraum der Zusammenhang innerhalb eines Computerprogramms, in dem ein Variablenname oder anderer Bezeichner gültig sind und verwendet werden können, oder innerhalb dessen eine Behauptung Wirkung hat. Außerhalb des Spielraums eines Variablennamens kann der Wert der Variable noch versorgt werden, und kann sogar irgendwie zugänglich sein, aber der Name bezieht sich darauf nicht; d. h. der Name wird zur Lagerung der Variable nicht gebunden.

Verschiedene Programmiersprachen haben verschiedene verschiedene Scoping-Regeln für verschiedene Arten von Behauptungen und Bezeichnern. Solche Scoping-Regeln haben eine große Wirkung auf die Sprachsemantik und, folglich, auf das Verhalten und die Genauigkeit von Programmen. Auf Sprachen wie C ++, auf eine ungebundene Variable zugreifend, hat bestimmte Semantik nicht und kann auf unbestimmtes Verhalten hinauslaufen; und Behauptungen oder außerhalb ihres Spielraums verwendete Bezeichner werden Syntax-Fehler erzeugen.

Spielraume werden oft an andere Sprachkonstruktionen gebunden, aber viele Sprachen bieten auch Konstruktionen spezifisch an, um Spielraum zu kontrollieren.

Spielraum innerhalb einer Funktion

Funktionsspielraum

fungieren Sie Quadrat (n) {\

geben Sie n * n zurück;

}\

fungieren Sie sum_of_squares (n) {\

var rösten = 0;//der Wert, um zurückzugeben

var i = 1;//ein Schalter, um von 1 bis n zu gehen

während (ich

Meistens verwendete Programmiersprachen bieten eine Weise an, eine lokale Variable in einer Funktion zu schaffen: Eine Variable, die, in einem Sinn, verschwindet, wenn die Funktion zurückkehrt.

Zum Beispiel, im Schnipsel des Codes von JavaScript am Recht, werden zwei Funktionen definiert: und. schätzt das Quadrat einer Zahl; rechnet die Summe von allen rechnet mit einer Zahl ab. (Zum Beispiel, ist 4 =, und ist 1 + 2 + 3 + 4 =.)

Jede dieser Funktionen ließ eine Variable nennen, die das Argument für die Funktion vertritt. Diese zwei Variablen sind völlig getrennt und ohne Beziehung, trotz, denselben Namen zu haben, weil sie lokale Variablen mit dem Funktionsspielraum sind: Jedes jemandes Spielraum ist seine eigene Funktion, so überlappen sie nicht. Deshalb, kann ohne sein eigenes rufen, das wird verändert. Ähnlich ließ Variablen nennen und; diese Variablen, wegen ihres beschränkten Spielraums, werden keine genannten Variablen stören, oder das könnte jeder anderen Funktion gehören. Mit anderen Worten gibt es keine Gefahr einer Namenkollision zwischen diesen Bezeichnern und irgendwelchen Bezeichnern ohne Beziehung, selbst wenn sie identisch sind.

Block-Spielraum innerhalb einer Funktion

interne Nummer sum_of_squares (interne Nummer n) {\

interne Nummer röstet = 0;

interne Nummer i = 1;

während (ich

Viele Sprachen nehmen Funktionsspielraum ein bisschen weiter, Variablen erlaubend, lokal zum gerade Teil einer Funktion gemacht zu werden; anstatt die komplette Funktion als sein Spielraum zu haben, könnte eine Variable Block-Spielraum haben, bedeutend, dass es scoped zu gerade einem einzelnen Block von Behauptungen ist. Das wird im C-Code am Recht demonstriert, das zwei verschiedene lokale genannte Variablen hat: Derjenige, dessen Spielraum die komplette Funktion und diejenige ist, die nur innerhalb - Schleife besteht. Tatsächlich schafft jede Wiederholung - Schleife ein neues Beispiel dessen. Das inner "verbirgt" "sich" völlig oder "Schatten" der Außen-, das solches, dass der Außen-innerhalb - Schleife unsichtbar ist — aber noch im Schleife-Kopfball verwendet werden kann,

Das ist ein eher erfundenes Beispiel; wirkliche C Programmierer nennen zwei lokale Variablen auf solche Art und Weise nicht gewöhnlich, dass man den anderen verbirgt. Außerdem erlauben einige Nachkommen von C, wie Java und C#, trotz, Unterstützung für das Block-Spielraum zu haben (darin kann eine lokale Variable gemacht werden, aus dem Spielraum vor dem Ende einer Funktion zu gehen), einer lokaler Variable nicht, einen anderen zu verbergen. Auf solchen Sprachen würde die versuchte Behauptung des zweiten auf einen Syntax-Fehler hinauslaufen, eine der Variablen würde umbenannt werden müssen.

Da der Hauptgebrauch von Blöcken innerhalb einer Funktion in Kontrollstrukturen solcher als - Behauptungen und - Schleifen ist, neigt Block-Spielraum dazu, das Spielraum von Variablen zur Struktur eines Flusses einer Funktion der Ausführung zu verbinden. Jedoch erlauben Sprachen mit dem Block-Spielraum normalerweise auch den Gebrauch von "nackten" Blöcken, die oft keinem anderen Zweck dienen als, feinkörnige Kontrolle des variablen Spielraums zu erlauben.

Gelassen Ausdrücke

Viele Sprachen, besonders funktionelle Sprachen, bieten eine Eigenschaft genannt lasse Ausdrücke an, die einem Spielraum einer Behauptung erlauben, ein einzelner Ausdruck zu sein. Das ist günstig, wenn, zum Beispiel, ein Zwischenwert für eine Berechnung erforderlich ist. Zum Beispiel, in Normalem ML, wenn Umsatz, dann ein Ausdruck ist, der zu mit einer vorläufigen Variable bewertet, die genannt ist, um zu vermeiden, zweimal zu rufen. Einige Sprachen mit dem Block-Spielraum kommen dieser Funktionalität durch das Angebot der Syntax für einen in einen Ausdruck einzubettenden Block näher; zum Beispiel konnte der ML oben erwähnte Standardausdruck in Perl als, oder im GNU C als geschrieben werden.

Spielraum außerhalb einer Funktion

Eine Behauptung hat globales Spielraum, wenn es Wirkung überall in einem kompletten Programm hat, oder (auf einigen Sprachen), wenn es Wirkung vom Punkt seines Ereignisses bis zum Ende der Quelldatei hat, kommt es darin vor. Der Letztere wird auch Dateispielraum genannt. Variablennamen mit dem globalen Spielraum — haben gerufen globale Variablen — werden oft als schlechte Praxis mindestens auf einigen Sprachen betrachtet; aber globales Spielraum wird normalerweise (abhängig von Sprache) für verschiedene andere Sorten von Bezeichnern, wie Namen von Funktionen und Namen von Klassen und anderen Datentypen verwendet. Im Schnipsel von JavaScript haben wir oben, die Funktionsnamen gesehen, und haben Sie aufrichtig globales Spielraum, während im C Schnipsel der Funktionsname Dateispielraum hat.

{mein $counter = 0;

U-Boot increment_counter

{$counter = $counter + 1;

geben Sie $counter zurück;

}\

}\</Quelle>

Einige Sprachen erlauben dem Konzept des Block-Spielraums, in unterschiedlichen Ausmaßen außerhalb einer Funktion angewandt zu werden. Zum Beispiel, im Schnipsel von Perl am Recht, ist ein Variablenname mit dem Block-Spielraum (wegen des Gebrauches des Schlüsselwortes), während ein Funktionsname mit dem globalen Spielraum ist. Jeder Anruf wird den Wert durch einen vergrößern, und den neuen Wert zurückgeben. Code außerhalb dieses Blocks kann rufen, aber kann nicht sonst erhalten oder den Wert dessen verändern.

Wie wir oben gesehen haben, sind Funktionsspielraum und Block-Spielraum sehr nützlich, um Namenkollisionen zu vermeiden, aber sogar am globalen Spielraum haben viele Sprachen Mechanismen wie namespaces, um zu helfen, dieses Problem zu lindern.

Lexikalischer scoping und dynamischer scoping

Wie wir, der Gebrauch von lokalen Variablen — von Variablennamen mit dem beschränkten Spielraum gesehen haben, besteht das nur innerhalb einer Sonderaufgabe — hilft, die Gefahr einer Namenkollision zwischen zwei identisch genannten Variablen zu vermeiden. Jedoch sind wir eine wichtige Frage ausgewichen: Was bedeutet es, "innerhalb" einer Funktion zu sein? Es gibt zwei sehr verschiedene Annäherungen an scoping, die auf diese Frage unterschiedlich antworten.

In lexikalischem scoping (oder lexikalischem Spielraum; auch genannt statischen scoping oder statisches Spielraum), wenn ein Spielraum eines Variablennamens eine bestimmte Funktion ist, dann ist sein Spielraum der Programm-Text der Funktionsdefinition: Innerhalb dieses Textes besteht der Variablenname, und wird zu seiner Variable gebunden, aber außerhalb dieses Textes besteht der Variablenname nicht. Im Vergleich, in dynamischem scoping (oder dynamischem Spielraum), wenn ein Spielraum eines Variablennamens eine bestimmte Funktion ist, dann ist sein Spielraum der Zeitabschnitt, während dessen die Funktion durchführt: Während die Funktion läuft, besteht der Variablenname, und wird zu seiner Variable gebunden, aber nach dem Funktionsumsatz besteht der Variablenname nicht. Das bedeutet dass, wenn Funktion eine getrennt definierte Funktion anruft, dann unter lexikalischem scoping hat Funktion Zugang zu 's lokale Variablen nicht (da der Text dessen nicht innerhalb des Textes dessen ist), während unter dynamischem scoping Funktion wirklich Zugang zu 's lokale Variablen hat (da die Beschwörung dessen innerhalb der Beschwörung ist).

x=1

fungieren Sie g {Echo-$x; x=2; }\

fungieren Sie f {lokaler x=3; g; }\

f # druckt das 1, oder 3?

Echo-$x # druckt das 1, oder 2?

</Quelle>

Denken Sie zum Beispiel, das Programm am Recht. Die erste Linie schafft eine globale Variable und initialisiert sie dazu. Die zweite Linie definiert eine Funktion, die ausdruckt (wirft) den aktuellen Wert dessen ("zurück"), und geht dann zu (das Überschreiben des vorherigen Werts) unter. Die dritte Linie, definiert eine Funktion, die eine lokale Variable (das Verbergen der identisch genannten globalen Variable) schafft und sie dazu initialisiert, und dann ruft. Die vierte Linie, Anrufe. Die fünfte Linie druckt den aktuellen Wert dessen aus. Also, was genau druckt dieses Programm? Es hängt von den Scoping-Regeln ab. Wenn die Sprache dieses Programms diejenige ist, die lexikalischen scoping verwendet, dann modifizieren Drucke und die globale Variable (weil draußen definiert wird), so druckt das Programm und dann. Im Vergleich, wenn diese Sprache dynamischen scoping verwendet, dann modifizieren Drucke und 's lokale Variable (weil aus genannt wird), so druckt das Programm und dann. (Wie es geschieht, ist die Sprache des Programms Heftiger Schlag, der dynamischen scoping verwendet; so druckt das Programm und dann.)

Lexikalischer scoping

Mit dem lexikalischen Spielraum bezieht sich ein Name immer auf seine (mehr oder weniger) lokale lexikalische Umgebung. Das ist ein Eigentum des Programm-Textes und wird unabhängig des Laufzeitanruf-Stapels durch die Sprachdurchführung gemacht. Weil dieses Zusammenbringen nur Analyse des statischen Programm-Textes verlangt, wird dieser Typ von scoping auch statischen scoping genannt. Lexikalischer scoping ist auf allen Algol-basierten Sprachen wie Pascal, Modula2 und Ada sowie auf modernen funktionellen Sprachen wie ML und Haskell normal. Es wird auch in der c Sprache und seinen syntaktischen und semantischen Verwandten, obwohl mit verschiedenen Arten von Beschränkungen verwendet. Statischer scoping erlaubt dem Programmierer, über Gegenstand-Verweisungen wie Rahmen, Variablen, Konstanten, Typen, Funktionen usw. als einfache Namenersetzungen vernünftig zu urteilen. Das macht es viel leichter, Modulcode und Grund darüber zu machen, da die lokale Namengeben-Struktur in der Isolierung verstanden werden kann. Im Gegensatz zwingt dynamisches Spielraum den Programmierer, alle möglichen dynamischen Zusammenhänge vorauszusehen, in denen der Code des Moduls angerufen werden kann.

Programm A;

var I:integer;

K:char;

Verfahren B;

var K:real;

L:integer;

Verfahren C;

var M:real;

beginnen Sie

(*scope A+B+C *)

Ende;

(*scope A+B *)

Ende;

(*scope *)

Ende.

</Quelle>

Denken Sie zum Beispiel das Programm-Bruchstück von Pascal am Recht. Die Variable ist an allen Punkten sichtbar, weil sie durch eine andere Variable desselben Namens nie verborgen wird. Die Variable ist nur im Hauptprogramm sichtbar, weil es durch die Variable verborgen wird, die im Verfahren und nur sichtbar ist. Variable ist auch nur im Verfahren sichtbar, und aber es verbirgt keine andere Variable. Variable ist nur im Verfahren sichtbar und deshalb entweder aus dem Verfahren oder aus dem Hauptprogramm nicht zugänglich. Außerdem ist Verfahren nur im Verfahren sichtbar und kann deshalb aus dem Hauptprogramm nicht genannt werden.

Es könnte ein anderes Verfahren gegeben haben, das im Programm außerhalb des Verfahrens erklärt ist. Der Platz im Programm, wo "" dann erwähnt wird, bestimmt, welches von den zwei Verfahren es genannt hat, vertritt so genau analog mit dem Spielraum von Variablen.

Die richtige Durchführung des statischen Spielraums auf Sprachen mit erstklassigen verschachtelten Funktionen ist nicht trivial, weil es verlangt, dass jeder Funktionswert damit eine Aufzeichnung der Werte der Variablen trägt, von denen es abhängt (das Paar der Funktion und diese Umgebung einen Verschluss genannt wird). Abhängig von der Durchführung und Computerarchitektur kann Variable lookup ein bisschen ineffizient werden, als sehr tief lexikalisch genistet hat, werden Funktionen verwendet, obwohl es wohl bekannte Techniken gibt, um das zu lindern. Außerdem für verschachtelte Funktionen, die sich nur auf ihre eigenen Argumente und (sofort) lokale Variablen beziehen, können alle Verhältnispositionen während der Übersetzung bekannt sein. Nicht oben überhaupt wird deshalb übernommen, wenn man diesen Typ der verschachtelten Funktion verwendet. Dasselbe gilt für besondere Teile eines Programms, wo verschachtelte Funktionen, und natürlich zu auf einer Sprache geschriebenen Programmen nicht verwendet werden, wo verschachtelte Funktionen (solcher als in der c Sprache) nicht verfügbar sind.

Geschichte

Lexikalischer scoping wurde für das Algol verwendet und ist auf den meisten anderen Sprachen seitdem aufgenommen worden. Tief verbindlich der statischem (lexikalischem) scoping näher kommt, wurde im LISPELN 1.5 (über das Gerät von Funarg eingeführt, das von Steve Russell entwickelt ist, unter John McCarthy arbeitend). Der ursprüngliche Lispeln-Dolmetscher (1960) und am frühsten Lispelt verwendeter dynamischer scoping, aber Nachkommen dynamisch scoped Sprachen nehmen häufig statischen scoping an; allgemeines Lispeln hat sowohl dynamischen als auch statischen scoping, während Schema statischen scoping exklusiv verwendet. Perl ist eine andere Sprache mit dynamischem scoping, der statischen scoping später hinzugefügt hat. Sprachen wie Pascal und C haben immer lexikalischen scoping gehabt, da sie beide unter Einfluss der Ideen sind, die in Algol 60 eingetreten sind (obwohl C lexikalisch verschachtelte Funktionen nicht eingeschlossen hat).

Dynamischer scoping

Mit dem dynamischen Spielraum hat jeder Bezeichner einen globalen Stapel von bindings. Das Einführen einer lokalen Variable mit dem Namen stößt eine Schwergängigkeit auf den globalen Stapel (der leer gewesen sein kann), der plötzlich verschwunden wird, wenn der Kontrollfluss das Spielraum verlässt. Das Auswerten in jedem Zusammenhang gibt immer die Spitzenschwergängigkeit nach. Mit anderen Worten bezieht sich ein globaler Bezeichner auf den mit der neusten Umgebung vereinigten Bezeichner. Bemerken Sie, dass das während der Übersetzung nicht getan werden kann, weil der verbindliche Stapel nur an der Durchlaufzeit besteht, die ist, warum dieser Typ von scoping dynamischen scoping genannt wird.

Allgemein werden bestimmte Blöcke definiert, um bindings zu schaffen, dessen Lebenszeit die Ausführungszeit des Blocks ist; das fügt einige Eigenschaften von statischem scoping zum dynamischen Scoping-Prozess hinzu. Jedoch, da eine Abteilung des Codes von vielen verschiedenen Positionen und Situationen genannt werden kann, kann es schwierig sein, am Anfang zu bestimmen, was bindings anwenden wird, wenn eine Variable verwendet wird (oder wenn man überhaupt besteht). Das kann vorteilhaft sein; die Anwendung des Grundsatzes von kleinsten Kenntnissen weist darauf hin, dass Code abhängig von den Gründen für (oder Verhältnisse) ein Wert einer Variable vermeidet, aber einfach den Wert gemäß der Definition der Variable verwendet. Diese schmale Interpretation von geteilten Daten kann ein sehr flexibles System zur Verfügung stellen, für das Verhalten einer Funktion zum aktuellen Staat (oder Politik) des Systems anzupassen. Jedoch verlässt sich dieser Vorteil auf die sorgfältige Dokumentation aller Variablen hat diesen Weg sowie auf der sorgfältigen Aufhebung von Annahmen über ein Verhalten einer Variable verwendet, und stellt keinen Mechanismus zur Verfügung, Einmischung zwischen verschiedenen Teilen eines Programms zu entdecken. Dynamischer scoping auch Leere alle Vorteile der Verweisungsdurchsichtigkeit. Als solcher kann dynamischer scoping gefährlich sein, und wenige neuere Sprachen verwenden ihn. Einige Sprachen, wie Perl und Common Lisp, erlauben dem Programmierer, statischen oder dynamischen scoping zu wählen, wenn sie definieren oder eine Variable wiederdefinieren. Logo und Lispeln von Emacs sind Beispiele von Sprachen, die dynamischen scoping verwenden.

Dynamischer scoping ist ziemlich leicht durchzuführen. Um einen Wert eines Bezeichners zu finden, konnte das Programm den Laufzeitstapel überqueren, jede Aktivierungsaufzeichnung (der Stapel-Rahmen jeder Funktion) für einen Wert für den Bezeichner überprüfend. In der Praxis wird das effizienter über den Gebrauch einer Vereinigungsliste gemacht, die ein Stapel von Paaren des Namens/Werts ist. Paare werden auf diesen Stapel gestoßen, wann auch immer Behauptungen gemacht und knallen gelassen werden, wann auch immer Variablen aus dem Spielraum gehen. Seichte Schwergängigkeit ist eine alternative Strategie, die beträchtlich schneller, von einer Hauptreferenztabelle Gebrauch machend ist, die jeden Namen mit seinem eigenen Stapel von Bedeutungen vereinigt. Das vermeidet eine geradlinige Suche während der Durchlaufzeit, um einen besonderen Namen zu finden, aber Sorge sollte genommen werden, um diesen Tisch richtig aufrechtzuerhalten. Bemerken Sie, dass beide dieser Strategien eine in umgekehrter Reihenfolge (LIFO) Einrichtung zu bindings für irgendwelche Variable annehmen; in der Praxis werden alle bindings so bestellt.

Eine noch einfachere Durchführung ist die Darstellung von dynamischen Variablen mit einfachen globalen Variablen. Die lokale Schwergängigkeit wird durch das Sparen des ursprünglichen Werts in einer anonymen Position auf dem Stapel durchgeführt, der für das Programm unsichtbar ist. Wenn dieses verbindliche Spielraum endet, wird der ursprüngliche Wert von dieser Position wieder hergestellt. Tatsächlich ist dynamisches Spielraum auf diese Weise entstanden. Frühe Durchführungen des Lispelns haben diese offensichtliche Strategie verwendet, um lokale Variablen durchzuführen, und die Praxis überlebt in einigen Dialekten, die noch im Gebrauch, wie GNU Emacs Lispeln sind. Lexikalisches Spielraum wurde ins Lispeln später eingeführt. Das ist zum obengenannten seichten verbindlichen Schema gleichwertig, außer dass die Hauptreferenztabelle einfach die globale variable verbindliche Umgebung ist, in der die Strom-Bedeutung der Variable sein globaler Wert ist. Das Aufrechterhalten von globalen Variablen ist nicht kompliziert. Zum Beispiel kann ein Symbol-Gegenstand ein hingebungsvolles Ablagefach für seinen globalen Wert haben.

Dynamischer scoping stellt eine ausgezeichnete Abstraktion für den Faden lokale Lagerung zur Verfügung, aber wenn es auf diese Weise verwendet wird, kann es nicht auf dem Sparen und der Wiederherstellung einer globalen Variable basieren. Eine mögliche Durchführungsstrategie ist für jede Variable, um einen mit dem Faden lokalen Schlüssel zu haben. Wenn auf die Variable zugegriffen wird, wird der mit dem Faden lokale Schlüssel verwendet, um auf die mit dem Faden lokale Speicherposition zuzugreifen (durch den Code, der durch den Bearbeiter erzeugt ist, der weiß, welche Variablen dynamisch sind, und die lexikalisch sind). Wenn der mit dem Faden lokale Schlüssel für den Benennen-Faden nicht besteht, dann wird die globale Position verwendet. Wenn eine Variable lokal gebunden wird, wird der vorherige Wert in einer verborgenen Position auf dem Stapel versorgt. Die mit dem Faden lokale Lagerung wird unter dem Schlüssel der Variable geschaffen, und der neue Wert wird dort versorgt. Weiter verschachtelt überreitet der Variable innerhalb dieses Fadens einfach sparen und stellen diese mit dem Faden lokale Position wieder her. Wenn das Spielraum der anfänglichen, äußersten Überfahrt endet, wird der mit dem Faden lokale Schlüssel gelöscht, die globale Version der Variable wieder zu diesem Faden ausstellend.

Qualifizierte Bezeichner

Wie wir gesehen haben, ist einer der Schlüsselgründe für das Spielraum, dass es hilft, Namenkollisionen zu verhindern, indem es identischen Bezeichnern erlaubt wird, sich auf verschiedene Dinge mit der Beschränkung zu beziehen, dass die Bezeichner getrennte Spielraume haben müssen. Manchmal ist diese Beschränkung ungünstig; wenn viele verschiedene Dinge überall in einem Programm, sie allgemein alle Bedürfnis-Bezeichner mit dem globalen Spielraum zugänglich sein müssen, so sind verschiedene Techniken erforderlich, Namenkollisionen zu vermeiden.

Um das zu richten, bieten viele Sprachen Mechanismen an, um globale Bezeichner zu organisieren. Die Details dieser Mechanismen und die gebrauchten Begriffe, hängen von der Sprache ab; aber die allgemeine Idee besteht darin, dass einer Gruppe von Bezeichnern selbst ein Name — ein Präfix — und, wenn notwendig, gegeben werden kann, kann auf eine Entität durch einen qualifizierten Bezeichner verwiesen werden, der aus dem Bezeichner plus das Präfix besteht. Normalerweise werden solche Bezeichner, gewissermaßen, zwei Sätze von Spielraumen haben: Ein Spielraum (gewöhnlich das globale Spielraum), in dem der qualifizierte Bezeichner, und ein oder mehr schmalere Spielraume sichtbar ist, in denen der unqualifizierte Bezeichner (ohne das Präfix) ebenso sichtbar ist. Und normalerweise können diese Gruppen selbst in Gruppen organisiert werden; d. h. sie können verschachtelt werden.

Obwohl viele Sprachen dieses Konzept unterstützen, ändern sich die Details außerordentlich. Einige Sprachen haben Mechanismen, wie namespaces in C ++ und C#, dieser Aufschlag fast exklusiv, um globalen Bezeichnern zu ermöglichen, in Gruppen organisiert zu werden. Andere Sprachen haben Mechanismen, wie Pakete in Ada und Strukturen in Normalem ML, diese Vereinigung das mit dem zusätzlichen Zweck, einigen Bezeichnern zu erlauben, nur anderen Mitgliedern ihrer Gruppe sichtbar zu sein. Und objektorientierte Sprachen erlauben häufig Klassen, oder Singleton protestiert, um diesen Zweck zu erfüllen (ob sie auch einen Mechanismus haben, für den das der primäre Zweck ist). Außerdem, Sprachen häufig meld diese Annäherungen; zum Beispiel sind die Pakete von Perl C ++ 's namespaces größtenteils ähnlich, aber verdoppeln sich fakultativ als Klassen für die objektorientierte Programmierung; und Java organisiert seine Variablen und Funktionen in Klassen, aber organisiert dann jene Klassen in Ada ähnliche Pakete.

Siehe auch

  • Verschluss (Informatik)
  • Globale Variable
  • Lokale Variable
  • Nichtlokale Variable
  • Name, der bindet
  • Namenentschlossenheit
  • Variablen (Spielraum und Ausmaß)
  • Informationsverheimlichung

Weiterführende Literatur


Source is a modification of the Wikipedia article Scope (computer science), licensed under CC-BY-SA. Full list of contributors here.
Cher Ami / Panthéon, Paris
Impressum & Datenschutz