ES3 dans les détails

Beaucoup de développeurs JavaScript savent que les variables sont intimement liées au contexte d'exécution :

var reportA = 10; // variable du contexte global

(function () {
    var reportB = 20; // variable locale d'un contexte de fonction
})();

alert(reportA); // 10
alert(reportB); // `reportB` n'est pas défini(e)

Beaucoup de développeurs savent également que la portée des variables est définie et limitée à l'exécution des contextes de fonctions. C'est-à-dire. que contrairement au C/C++, pour la structure de contrôle de boucle for par exemple, aucun contexte local n'est créé en JavaScript :

for (var report in { reportA: 1, reportB: 2 }) {
    alert(report);
}

alert(report); // la variable `report` est toujours dans la portée même si la boucle est terminée

Regardons plus en détail ce qu'il se passe quand nous déclarons nos données.

Si les variables sont liées à leur contexte d'exécution, celui-ci doit savoir où leurs données sont stockées et comment y accéder. Le mécanisme permettant cela est appelé l'objet des variables.

L'objet des variables (dont la forme abrégée sera VO pour « variable object ») est un objet spécial lié à un contexte d'exécution et qui stocke :

• les déclarations de variables (dont la forme abrégée sera VD pour « variable declaration »),
• les déclarations de fonctions (dont la forme abrégée sera FD pour « function declaration »),
• les paramètres formels de fonctions (dont la forme abrégée sera FP pour « formal parameters »)

déclarés dans un contexte.

De façon schématique dans ces exemples, il est possible de présenter l'objet des variables comme un objet JavaScript standard :

VO = {}

Et comme nous l'avons dit, l'objet des variables est une propriété d'un contexte d'exécution :

activeExecutionContext = {
    VO: {
        <...> // données du contexte `VD`, `FD` (et `FP`)
    }
}

Il est possible d'avoir accès à l'objet des variables du contexte global par l'intermédiaire de l'objet global (car l'objet global est lui-même l'objet des variables dans ce cas). Pour tous les autres contextes, faire référence à l'objet des variables est impossible, c'est un mécanisme du moteur.

Quand nous déclarons une variable ou une fonction dans le contexte global, ce n'est rien d'autre que la création d'une nouvelle propriété au sein de l'objet des variables avec le nom et la valeur de notre variable (ou fonction).

Exemple :

var reportA = 10;

function precogs(minorityReport) {
    var reportB = 20;
};

precogs(30);

Avec les objets des variables correspondants :

// Objet des variables du contexte global
VO(globalContext) = {
    reportA: 10,
    precogs: <référence à la `FD` `precogs`>
}

// Objet des variables du contexte de la fonction `precogs`
VO(<precogs> functionContext) = {
    minorityReport: 30,
    reportB: 20
}

Voilà pour une vision théorique. Il faut juste être conscient qu'au niveau de l'implémentation réelle, l'objet des variables est quelque chose d'abstrait. Dans un contexte d'exécution réel, VO porte un autre nom et à une structure probablement différente.

Certaines opérations (comme l'affectation des variables) et comportements de l'objet des variables sont identiques pour toutes les déclinaisons de contexte d'exécution.

Pour expliquer cela, il va être nécessaire de présenter une partie de l'objet des variables comme commun à toutes les déclinaisons et une partie définissant des éléments et comportements additionnels.

VO // contient des `VD` et des `FD`
║
╠══> VO(globalContext) === GO === this
║
╚══> VO(functionContext) === AO // contient des `FP` et l'`ArgO`

Voyons cela plus en détail.

III-A. L'objet des variables dans le contexte global▲

activeGlobalContext = {
    GO: {
        Math: <...>,
        String: <...>,
        document: <...>,
        <...>,
        window: GO
    }
}

activeGlobalContext = {
    GO: {
        Math: <...>,
        String: <...>,
        process: <...>,
        <...>,
        global: GO
    }
}

// sans préfixe
String(10); // === `GO.String(10)` mais `GO` n'est pas accessible

// avec préfixes
window.a = 10; // === `GO.window.a = 10` === `GO.a = 10`
this.b = 20; // === `GO.b = 20`

VO(globalContext) === GO

var mr = new String('test');

alert(mr); // accès direct, elle est trouvée dans `VO(globalContext)['mr']` => `'test'`

alert(window['mr']); // accès indirect via `GO.window['mr']` === `GO['mr']` === `VO(globalContext)['mr']` => `'test'`
alert(mr === this.mr); // `true`

var mrKey = 'mr';
alert(window[mrKey]); // accès indirect avec la résolution d'identifiant dynamique de propriété => `'test'`

III-B. L'objet des variables dans un contexte de fonction▲

VO(functionContext) === AO

activeFunctionContext = {
    AO: {
        <...>, // données du contexte `VD`, `FD` et `FP`
        arguments: <ArgO>
    }
}

function precogs(xReport, yReport, zReport) {

  // quantité de paramètres définis : xReport, yReport et zReport
  alert(precogs.length); // `3`

  // quantité d'arguments réellement passés : seulement xReport et yReport
  alert(arguments.length); // `2`

  // référence de la fonction à elle-même
  alert(arguments.callee === precogs); // `true`

  // paramètres partagés

  alert(xReport === arguments[0]); // `true`
  alert(xReport); // 10

  arguments[0] = 20;
  alert(xReport); // `20`

  xReport = 30;
  alert(arguments[0]); // `30`

  // cependant, pour l'argument non passé zReport,
  // le array-index de l'objet
  // des arguments n'est pas partagé

  zReport = 40;
  alert(arguments[2]); // `undefined`

  arguments[2] = 50;
  alert(zReport); // `40`

}

precogs(10, 20);

Après quelques mises au point, nous avons enfin atteint le sujet principal de ce tutoriel : le traitement du code des contextes d'exécution. Ce traitement est divisé en deux phases :

1. Entrée dans le contexte d'exécution ;
2. Exécution du code.

Les modifications de l'objet des variables sont intimement liées à ces deux phases.

IV-A. Entrée dans le contexte d'exécution▲

function precogs(reportA, reportB) {
    var minorityReport = 10;
    function agatha() {}
    var dashiell = function dash() {};
    (function arthur() {});
}

precogs(10); // appel

AO(<precogs>) = {
    reportA: 10,
    reportB: undefined,
    minorityReport: undefined,
    agatha: <référence à la FD `agatha`>
    dashiell: undefined
}

IV-B. Exécution du code▲

AO['minorityReport'] = 10
AO['dashiell'] = <référence à la `FE` `dash`>

alert(john); // `function john() {}`

var john = 10;
alert(john); // `10`

john = 20;

function john() {}

alert(john); // `20`

VO = {}

VO['john'] = <référence à la `FD` `john`>

// `var john = 10;` trouvée
// si la fonction `john` n'avait pas déjà été définie
// et bien `john` aurait été `undefined`, mais dans notre cas
// la déclaration de variable n'affecte pas
// la valeur de la fonction avec le même nom

VO['john'] = <la valeur n'est pas affectée, toujours la `FD`>

VO['john'] = 10
VO['john'] = 20

if (true) {
    var reportA = 1;
} else {
    var reportB = 2;
}

alert(reportA); // `1`
alert(reportB); // `undefined`, mais pas « erreur : `reportB` n'est pas défini(e) »

Comme dit plus haut, une page web n'exécute pas un Programme JavaScript, mais autant de programmes qu'elle rencontre de balises <script>, d'éléments HTMLScriptElement ou encore de code à exécuter en tant que JavaScript (attribut onclick, href="javascripst: ...", etc.). Il en résulte qu'il n'existe pas « un » contexte global, mais des contextes globaux. Cependant, tous ces contextes utilisent le même objet global.

Les phases d'entrée dans le contexte global et d'exécution du code global sont donc réitérées pour chaque nouveau programme (<script>, etc.). Mais à chaque fois, l'objet global (déjà disponible dès l'entrée dans le contexte) contient les déclarations de variables récupérées des contextes globaux précédents. Parce que les contextes globaux sont activés dans le même ordre que les programmes sont trouvés et qu'il n'existe pas de phase « d'entrée dans la page web », toute déclaration de variables venant du contexte global d'un programme qui sera exécuté plus tard n'est pas accessible dans le contexte global courant. À l'inverse, toute déclaration de variables venant du contexte global d'un programme qui a déjà été exécuté est disponible et accessible. C'est la même chose pour les déclarations de fonctions. Voyons cela avec ces exemples :

<script>
    // Le script `echo1` sera analysé en premier

    console.log(arthur); // `function arthur() {}`
    console.log(agatha); // « error : `agatha` n'est pas défini(e) »
    console.log(dashiell); // « error : `dashiell` n'est pas défini(e) »

    function arthur() {}
</script>
<script>
    // Le script `echo2` sera analysé en second

    console.log(arthur); // `function arthur() {}`
    console.log(agatha); // `10`
    console.log(dashiell); // `function dashiell() {}`

    var agatha = 10;
    function dashiell() {}
</script>

Cela remplit notre objet global consécutivement des manières suivantes : pour le premier script

GO(<echo1>) = {
    arthur: <référence à la FD `arthur`>
}

et pour le second script

GO(<echo2>) = {
    arthur: <référence à la FD `arthur`>, // déjà présent dans l'objet global et trouvé d'un précédent programme
    agatha: undefined,
    dashiell: <référence à la FD `dashiell`>
}

Nous voyons donc pourquoi lors de la phase d'exécution, le premier script retourne une erreur pour agatha et dashiell qui n'existeront dans l'objet global qu'après la phase d'entrée dans le contexte du script2.

Notez également que par conséquent, de la même manière que l'ordre des instructions d'un code est important, l'ordre dans lequel les scripts sont appelés l'est aussi, car il peut changer le fonctionnement d'un programme.

<script>
    // Ce script `echo2` sera analysé en premier

    console.log(arthur); // « error : `arthur` n'est pas défini(e) »
    console.log(agatha); // `10`
    console.log(dashiell); // `function dashiell() {}`

    var agatha = 10;
    function dashiell() {}
</script>
<script>
    // Ce script `echo1` sera analysé en second

    console.log(arthur); // `function arthur() {}`
    console.log(agatha); // `10`
    console.log(dashiell); // `function dashiell() {}`

    function arthur() {}
</script>

à cause de l'état de l'objet global évoluant ainsi :

GO(<echo2>) = {
    agatha: 10,
    dashiell: <référence à la FD `dashiell`>
}

et

GO(<echo1>) = {
    agatha: 10, // déjà présent dans l'objet global et trouvé d'un précédent programme
    dashiell: <référence à la FD `dashiell`>  // déjà présent dans l'objet global et trouvé d'un précédent programme
    arthur: <référence à la FD `arthur`>
}

On voit souvent dans différents articles (et même livres) sur le JavaScript l'affirmation suivante : « il est possible de déclarer une variable globale en utilisant le mot-clé var (dans le contexte global) et sans le mot-clé var (depuis n'importe quel contexte) ». Ce n'est pas exactement ça. Soyez assuré de cela :

les variables se déclarent uniquement avec le mot-clé var.

Et des affectations comme ci-dessous :

reportA = 10;

créent simplement une nouvelle propriété dans l'objet global, mais pas une variable. « Pas une variable », mais pas dans le sens qu'elle ne pourra pas être changée lors de la phase d'exécution (on pourra y accéder, car VO(globalContext) === GO), mais « pas une variable » dans le sens qu'elle n'est pas dans l'objet des variables lors de la phase d'entrée.

Regardons cet exemple pour tester la différence :

alert(reportA); // `undefined`
alert(reportB); // « erreur, `reportB` n'est pas défini(e) »

reportB = 10;
var reportA = 20;

La différence vient de l'objet des variables et des phases où il est modifié (phase d'entrée dans le contexte et phase d'exécution de code) :

Pour l'entrée dans le contexte :

VO = {
    reportA: undefined
}

Nous voyons qu'il n'existe aucune variable reportB. reportB n'apparaîtra que lors de la phase d'exécution du code (et dans notre cas reportB n'apparaîtra pas, car il va y avoir une erreur).

Changeons le code :

alert(reportA); // `undefined`, nous savons pourquoi

reportB = 10;
alert(reportB); // `10`, créée lors de l'exécution du code

var reportA = 20;
alert(reportA); // `20`, modifiée lors de l'exécution du code

Voici le point important en ce qui concerne les variables. Les variables, par opposition aux simples propriétés, ont un attribut {DontDelete}, ce qui signifie qu'il est impossible de les supprimer avec l'opérateur delete :

reportA = 10;
alert(window.reportA); // `10`

alert(delete reportA); // `true`

alert(window.reportA); // `undefined`

var reportB = 20;
alert(window.reportB); // `20`

alert(delete reportB); // `false`

alert(window.reportB); // toujours `20`

Cependant, il y a un contexte d'exécution où cette règle n'a pas d'effet. C'est le contexte eval : l'attribut {DontDelete} n'est pas appliqué pour les variables :

eval('var minorityReport = 10;');
alert(window.minorityReport); // `10`

alert(delete minorityReport); // `true`

alert(window.minorityReport); // `undefined`

Si en essayant votre code dans une console JavaScript, vous pouvez supprimer une variable, c'est que cette console utilise eval pour évaluer votre code.

Comme nous l'avons déjà mentionné, conformément au standard, accéder directement à l'objet d'activation est impossible. Cependant, dans plusieurs moteurs comme celui de Mozilla Firefox (SpiderMonkey) ou Rhino les fonctions ont une propriété spéciale __parent__ qui est une référence à l'objet d'activation (ou à l'objet global) dans lequel ces fonctions ont été créées.

Exemple (SpiderMonkey et Rhino) :

var GO = this;
var minorityReport = 10;

function agatha() {}

alert(agatha.__parent__); // `GO`

var VO = agatha.__parent__;

alert(VO.minorityReport); // `10`
alert(VO === GO); // `true`

Dans l'exemple ci-dessus, nous voyons que agatha est créée dans le contexte global et sa propriété __parent__ est ajoutée à l'objet des variables du contexte global, c.-à-d. à l'objet global.

Cependant obtenir l'objet d'activation dans SpiderMonkey de la même manière n'est pas possible : cela dépendra de la version, mais __parent__ pour des fonctions dans des fonctions retournera null ou l'objet global.

Dans Rhino, l'accès à l'objet d'activation est permis et disponible de cette manière :

Exemple (Rhino) :

var GO = this;
var reportA = 10;

(function dashiell() {

    var reportB = 20;

    // l'objet d'activation du contexte `dashiell`
    var AO = (function () {}).__parent__;

    print(AO.reportB); // 20

    // __parent__ de l'objet d'activation
    // courant est déjà l'objet global,
    // c.-à-d. qu'une chaîne spéciale d'objets des variables est formée,
    // on la nomme : chaîne des portées
    print(AO.__parent__ === GO); // `true`

    print(AO.__parent__.reportA); // `10`

})();

Dans ce tutoriel, nous avons vu plus en détail l'étude des objets relatifs aux contextes d'exécution. Les prochains chapitres seront consacrés à la résolution des identifiants, aux chaînes des portées et, par conséquent, aux fermetures en JavaScript.

Nous remercions Bruno Lesieur qui nous a autorisés à publier ce tutoriel.

Nous remercions également Laethy pour la mise au gabarit et Claude Leloup pour la correction orthographique.