Эксперты по JavaScript: почему `with` сводит на нет оптимизацию компилятора, связанную с областью видимости

Упомянутая здесь оптимизация основана на следующем факте: переменные, объявленные внутри функции, всегда можно определить с помощью простого статического анализа кода (т. е. путем просмотра объявлений var/let и function), а набор объявленных переменных внутри функции функция никогда не меняется.

eval нарушает это предположение, предоставляя возможность изменять локальную привязку (путем введения новых переменных в область действия функции во время выполнения). with нарушает это предположение, вводя новую нелексическую привязку внутри функции, свойства которой вычисляются во время выполнения. Статический анализ кода не всегда может определить свойства объекта with, поэтому анализатор не может определить, какие переменные существуют в блоке with. Важно отметить, что объект, предоставленный with, может изменяться между выполнениями функции, а это означает, что набор переменных в этом лексическом разделе функции никогда не может быть гарантированно непротиворечивым.

Рассмотрим простую функцию:

function foo() {
    var a, b;
    function c() { ... }
    ...
}

Все точки в foo имеют три переменные локальной области видимости: a, b и c. Оптимизатор может прикрепить к функции постоянную «примечание», в котором говорится: «Эта функция имеет три переменные: a, b и c. Это никогда не изменится».

Теперь рассмотрим:

function bar(egg) {
    var a, b;
    function c() { ... }

    with(egg) {
        ...
    }
}

В блоке with неизвестно, какие переменные будут или не будут существовать. Если в with есть a, b или c, мы не знаем до времени выполнения, относится ли это к переменной bar или к переменной, созданной лексической областью видимости with(egg).

Чтобы показать полупрактический пример того, как это проблема, наконец, рассмотрим:

function baz(egg) {
    with(egg) {
        return function() { return whereami; }
    }
}

Когда выполняется внутренняя функция (например, bar({...})()), механизм выполнения просматривает цепочку областей видимости, чтобы найти whereami. Если бы оптимизатору было разрешено прикрепить постоянную примечание к baz, то исполняющая машина немедленно узнала бы, что в замыкании baz функции находится значение whereami, потому что это гарантированно будет домом для whereami (любого аналогичного значения). именованная переменная вверх по цепочке областей действия будет затенена ближайшей). Однако он не знает, существует ли whereami в baz или нет, потому что он может быть условно создан содержимым egg в конкретном запуске bar, который создал эту внутреннюю функцию. Поэтому его приходится проверять, а оптимизацию не использовать.

Возьмите этот пример:

{
 let a = 1; //stored at 123
 {
   let b = 2; //stored at 124
   console.log(a/*123*/,b/*124*/);
 }
}

А теперь это:

{
 let a = 1;//stored at 123
 with({a:3}){
   console.log(a /*123 ??*/);
 }
}