Есть ли законное использование оператора «with» в JavaScript?

Visual Basic.NET имеет аналогичный оператор With. Один из наиболее распространенных способов, которыми я его использую, - это быстрое задание ряда свойств. Вместо:

someObject.Foo = ''
someObject.Bar = ''
someObject.Baz = ''

, Я могу написать:

With someObject
    .Foo = ''
    .Bar = ''
    .Baz = ''
End With

Дело не только в лени. Это также делает код более читаемым. И, в отличие от JavaScript, он не страдает двусмысленностью, так как вам нужно добавить префикс . (точка) ко всему, на что влияет этот оператор. Итак, следующие два четко различаются:

With someObject
    .Foo = ''
End With

против.

With someObject
    Foo = ''
End With

Первый - someObject.Foo; последний - Foo в области действия за пределамиsomeObject.

Я считаю, что отсутствие различий в JavaScript делает его гораздо менее полезным, чем вариант Visual Basic, поскольку слишком высок риск двусмысленности. Помимо этого, with по-прежнему является мощной идеей, которая может улучшить читаемость.

Я думаю, что очевидное использование - это ярлык. Если вы, например, инициализируя объект, вы просто экономите, набирая много «ObjectName». Что-то вроде "with-slots" в lisp, которое позволяет писать

(with-slots (foo bar) objectname
   "some code that accesses foo and bar"

что то же самое, что писать

"some code that accesses (slot-value objectname 'foo) and (slot-value objectname 'bar)""

Более очевидно, почему это ярлык, чем когда ваш язык позволяет "Objectname.foo", но все же.

Имея опыт работы с Delphi, я бы сказал, что использование с должно быть последней возможностью оптимизации размера, возможно, выполняемой каким-то алгоритмом минимизатора javascript с доступом к статическому анализу кода для проверки его безопасности.

Проблемы с областью видимости, с которыми вы можете столкнуться при либеральном использовании оператора с, могут стать настоящей головной болью в **, и я бы не хотел, чтобы кто-либо испытал сеанс отладки, чтобы выяснить, что он .. происходит в вашем коде. только для того, чтобы узнать, что он захватил член объекта или неправильную локальную переменную вместо вашей глобальной или внешней переменной области видимости, которую вы намеревались.

Оператор VB с лучше тем, что ему нужны точки для устранения неоднозначности области видимости, но оператор Delphi с - это заряженный пистолет с hairtrigger, и мне кажется, что javascript достаточно похож, чтобы гарантировать такое же предупреждение.

Вы можете определить небольшую вспомогательную функцию, чтобы обеспечить преимущества with без двусмысленности:

var with_ = function (obj, func) { func (obj); };

with_ (object_name_here, function (_)
{
    _.a = "foo";
    _.b = "bar";
});

Я просто не понимаю, почему использование with более читаемо, чем просто набирать object.member. Я не думаю, что он стал менее читаемым, но и не думаю, что он стал читаемее.

Как сказал lassevk, я определенно вижу, что использование with будет более подвержено ошибкам, чем просто использование очень явного синтаксиса «object.member».

Использование with также замедляет ваш код во многих реализациях, так как теперь все оборачивается дополнительной областью поиска. Нет законной причины для использования with в JavaScript.

Как указывалось в моих предыдущих комментариях, я не думаю, что вы можете безопасно использовать with, независимо от того, насколько заманчиво это может быть в той или иной ситуации. Поскольку здесь вопрос не освещается, повторюсь. Рассмотрим следующий код

user = {};
someFunctionThatDoesStuffToUser(user);
someOtherFunction(user);

with(user){
    name = 'Bob';
    age  = 20;
}

Без тщательного исследования этих вызовов функций невозможно определить, в каком состоянии будет находиться ваша программа после выполнения этого кода. Если user.name уже был установлен, теперь это будет Bob. Если он не был установлен, глобальный name будет инициализирован или изменен на Bob, а объект user останется без свойства name.

Ошибки случаются. Если вы используете с, вы в конечном итоге сделаете это и увеличите шансы, что ваша программа потерпит неудачу. Хуже того, вы можете столкнуться с рабочим кодом, который устанавливает глобальное значение в блоке with либо намеренно, либо из-за того, что автор не знает об этой причуде конструкции. Это очень похоже на провал при переключении: вы понятия не имеете, задумал ли автор это, и нет никакого способа узнать, приведет ли «исправление» кода к регрессии.

Современные языки программирования полны функций. Некоторые функции после многих лет использования оказываются плохими, и их следует избегать. Javascript with - один из них.

Вряд ли стоит того, ведь вы можете сделать следующее:

var o = incrediblyLongObjectNameThatNoOneWouldUse;
o.name = "Bob";
o.age = "50";

Я думаю, что оператор with может пригодиться при преобразовании языка шаблонов в JavaScript. Например JST в base2, но я видел это чаще.

Я согласен, что это можно запрограммировать без оператора with. Но поскольку это не создает никаких проблем, это законное использование.

Я думаю, что полезность with может зависеть от того, насколько хорошо написан ваш код. Например, если вы пишете код, который выглядит следующим образом:

var sHeader = object.data.header.toString();
var sContent = object.data.content.toString();
var sFooter = object.data.footer.toString();

то вы можете утверждать, что with улучшит читаемость кода, сделав следующее:

var sHeader = null, sContent = null, sFooter = null;
with(object.data) {
    sHeader = header.toString();
    sContent = content.toString();
    sFooter = content.toString();
}

И наоборот, можно утверждать, что вы нарушаете Закон Деметры, но, опять же, возможно, нет. Я отвлекся =).

Прежде всего, знайте, что Дуглас Крокфорд рекомендует нет с использованием with. Я настоятельно рекомендую вам прочитать его сообщение в блоге о with и его альтернативах здесь.

Сегодня мне пришло в голову другое использование, поэтому я взволнованно поискал в Интернете и нашел существующее упоминание о нем: Определение переменных внутри области видимости блока.

Фон

JavaScript, несмотря на его внешнее сходство с C и C++, не связывает переменные с блоком, в котором они определены:

var name = "Joe";
if ( true )
{
   var name = "Jack";
}
// name now contains "Jack"

Объявление замыкания в цикле - распространенная задача, которая может привести к ошибкам:

for (var i=0; i<3; ++i)
{
   var num = i;
   setTimeout(function() { alert(num); }, 10);
}

Поскольку цикл for не вводит новую область видимости, тот же num - со значением 2 - будет использоваться всеми тремя функциями.

Новый объем: let и with

С введением оператора let в ES6 стало легко ввести новую область видимости, когда это необходимо, чтобы избежать этих проблем:

// variables introduced in this statement 
// are scoped to each iteration of the loop
for (let i=0; i<3; ++i)
{
   setTimeout(function() { alert(i); }, 10);
}

Или даже:

for (var i=0; i<3; ++i)
{
   // variables introduced in this statement 
   // are scoped to the block containing it.
   let num = i;
   setTimeout(function() { alert(num); }, 10);
}

Пока ES6 не станет универсальным, его использование будет ограничено новейшими браузерами и разработчиками, желающими использовать транспилеры. Однако мы можем легко смоделировать это поведение с помощью with:

for (var i=0; i<3; ++i)
{
   // object members introduced in this statement 
   // are scoped to the block following it.
   with ({num: i})
   {
      setTimeout(function() { alert(num); }, 10);
   }
}

Теперь цикл работает так, как задумано, создавая три отдельные переменные со значениями от 0 до 2. Обратите внимание, что переменные, объявленные в в блоке, не привязаны к нему, в отличие от поведения блоков в C++ (в C переменные должны быть объявлены в начале блок, так что в некотором роде он похож). Это поведение на самом деле очень похоже на Синтаксис блока let, представленное в более ранних версиях браузеров Mozilla, но не получившее широкого распространения в других местах.

Да, да и да. Есть вполне законное использование. Смотреть:

with (document.getElementById("blah").style) {
    background = "black";
    color = "blue";
    border = "1px solid green";
}

По сути, любые другие хуки DOM или CSS отлично подходят для использования с. Это не похоже на то, что «CloneNode» будет неопределенным и вернется в глобальную область видимости, если только вы не сделали все возможное и не решили сделать это возможным.

Жалоба Крокфорда на скорость заключается в том, что новый контекст создается с помощью. Контексты обычно дороги. Я согласен. Но если вы только что создали div и у вас нет под рукой какой-либо инфраструктуры для настройки CSS и вам нужно вручную настроить 15 или около того свойств CSS, то создание контекста, вероятно, будет дешевле, чем создание переменных и 15 разыменований:

var element = document.createElement("div"),
    elementStyle = element.style;

elementStyle.fontWeight = "bold";
elementStyle.fontSize = "1.5em";
elementStyle.color = "#55d";
elementStyle.marginLeft = "2px";

так далее...

Я использовал оператор with как простую форму импорта с заданной областью. Допустим, у вас есть какой-то конструктор разметки. Вместо того, чтобы писать:

markupbuilder.div(
  markupbuilder.p('Hi! I am a paragraph!',
    markupbuilder.span('I am a span inside a paragraph')
  )
)

Вместо этого вы можете написать:

with(markupbuilder){
  div(
    p('Hi! I am a paragraph!',
      span('I am a span inside a paragraph')
    )
  )
}

Для этого варианта использования я не выполняю никаких назначений, поэтому у меня нет проблемы неоднозначности, связанной с этим.

Я никогда не использую, не вижу причин и не рекомендую.

Проблема с with заключается в том, что предотвращает многочисленные лексические оптимизации может выполнять реализация ECMAScript. Учитывая рост быстрых двигателей на основе JIT, этот вопрос, вероятно, станет еще более важным в ближайшем будущем.

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

Оператор with может использоваться для уменьшения размера кода или для частных членов класса, например:

// demo class framework
var Class= function(name, o) {
   var c=function(){};
   if ( o.hasOwnProperty("constructor") ) {
       c= o.constructor;
   }
   delete o["constructor"];
   delete o["prototype"];
   c.prototype= {};
   for( var k in o ) c.prototype[k]= o[k];
   c.scope= Class.scope;
   c.scope.Class= c;
   c.Name= name;
   return c;
}
Class.newScope= function() {
    Class.scope= {};
    Class.scope.Scope= Class.scope;
    return Class.scope;
}

// create a new class
with( Class.newScope() ) {
   window.Foo= Class("Foo",{
      test: function() {
          alert( Class.Name );
      }
   });
}
(new Foo()).test();

Оператор with очень полезен, если вы хотите изменить область видимости, что необходимо для вашей собственной глобальной области видимости, которой вы можете управлять во время выполнения. Вы можете добавить к нему константы или некоторые часто используемые вспомогательные функции, например, «toUpper», «toLower» или «isNumber», «clipNumber» aso ..

О плохой производительности я часто читал: определение области действия функции не повлияет на производительность, на самом деле в моем FF функция с областью действия выполняется быстрее, чем функция без области действия:

var o = {x: 5},r, fnRAW= function(a,b){ return a*b; }, fnScoped, s, e, i;
with( o ) {
    fnScoped= function(a,b){ return a*b; };
}

s= Date.now();
r= 0;
for( i=0; i < 1000000; i++ ) {
    r+= fnRAW(i,i);
}
e= Date.now();
console.info( (e-s)+"ms" );

s= Date.now();
r= 0;
for( i=0; i < 1000000; i++ ) {
    r+= fnScoped(i,i);
}
e= Date.now();
console.info( (e-s)+"ms" );

Таким образом, при использовании вышеупомянутого способа оператор with не оказывает отрицательного влияния на производительность, но является хорошим, поскольку снижает размер кода, что влияет на использование памяти на мобильных устройствах.

Это хорошо для помещения кода, который выполняется в относительно сложной среде, в контейнер: я использую его для создания локальной привязки для «окна» и тому подобного для запуска кода, предназначенного для веб-браузера.

Я думаю, что буквальное использование объекта интересно, как замена для использования замыкания

for(var i = nodes.length; i--;)
{
       // info is namespaced in a closure the click handler can access!
       (function(info)
       {           
            nodes[i].onclick = function(){ showStuff(info) };
       })(data[i]);
}

или оператор with, эквивалентный закрытию

for(var i = nodes.length; i--;)
{
       // info is namespaced in a closure the click handler can access!
       with({info: data[i]})
       {           
            nodes[i].onclick = function(){ showStuff(info) };
       }        
}

Я думаю, что реальный риск заключается в случайном минипулировании переменных, которые не являются частью оператора with, поэтому мне нравится, что литерал объекта передается с помощью, вы можете точно увидеть, что он будет в добавленном контексте в коде.

Использование «with» может сделать ваш код более сухим.

Рассмотрим следующий код:

var photo = document.getElementById('photo');
photo.style.position = 'absolute';
photo.style.left = '10px';
photo.style.top = '10px';

Вы можете высушить его до следующего:

with(document.getElementById('photo').style) {
  position = 'absolute';
  left = '10px';
  top = '10px';
}

Думаю, это зависит от того, предпочитаете ли вы разборчивость или выразительность.

Первый пример более разборчив и, вероятно, рекомендуется для большей части кода. Но большая часть кода в любом случае довольно ручная. Второй вариант немного более неясен, но использует выразительную природу языка, чтобы сократить размер кода и лишние переменные.

Я полагаю, что люди, которым нравится Java или C#, выберут первый способ (object.member), а те, кто предпочитает Ruby или Python, выберут второй.

Я создал функцию «слияния», которая устраняет часть этой двусмысленности с помощью оператора with:

if (typeof Object.merge !== 'function') {
    Object.merge = function (o1, o2) { // Function to merge all of the properties from one object into another
        for(var i in o2) { o1[i] = o2[i]; }
        return o1;
    };
}

Я могу использовать его так же, как with, но я знаю, что это не повлияет ни на одну область действия, на которую я не собираюсь влиять.

Использование:

var eDiv = document.createElement("div");
var eHeader = Object.merge(eDiv.cloneNode(false), {className: "header", onclick: function(){ alert("Click!"); }});
function NewObj() {
    Object.merge(this, {size: 4096, initDate: new Date()});
}

Вы можете использовать with, чтобы представить содержимое объекта как локальные переменные для блока, как это делается с этим небольшой шаблонизатор.

Вы должны увидеть проверку формы в javascript в W3schools http://www.w3schools.com/js/js_form_validation.asp, где форма объекта "сканируется", чтобы найти вход с именем 'email'

Но я изменил его, чтобы из ЛЮБОЙ формы все поля проверялись как непустые, независимо от имени или количества полей в форме. Я тестировал только текстовые поля.

Но with () упростил задачу. Вот код:

function validate_required(field)
{
with (field)
  {
  if (value==null||value= = "")
    {
    alert('All fields are mandtory');return false;
    }
  else
    {
    return true;
    }
  }
}

function validate_form(thisform)
{
with (thisform)
  {
    for(fiie in elements){
        if (validate_required(elements[fiie])==false){
            elements[fiie].focus();
            elements[fiie].style.border='1px solid red';
            return false;
        } else {elements[fiie].style.border='1px solid #7F9DB9';}
    }

  }
  return false;
}

Недавно я обнаружил, что инструкция with невероятно полезна. Этот метод никогда не приходил мне в голову, пока я не начал свой текущий проект - консоль командной строки, написанную на JavaScript. Я пытался имитировать API консоли Firebug / WebKit, где в консоль можно вводить специальные команды, но они не отменяют никакие переменные в глобальной области. Я подумал об этом, когда пытался решить проблему, о которой упоминал в комментариях к Отличный ответ Shog9.

Чтобы добиться этого эффекта, я использовал два оператора with, чтобы «наслоить» область видимости на глобальную:

with (consoleCommands) {
    with (window) {
        eval(expression); 
    }
}

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

Я был вдохновлен опубликовать этот ответ, когда, к моему удивлению, мне удалось найти ту же технику, которая используется в других местах - Исходный код Chromium!

InjectedScript._evaluateOn = function(evalFunction, object, expression) {
    InjectedScript._ensureCommandLineAPIInstalled();
    // Surround the expression in with statements to inject our command line API so that
    // the window object properties still take more precedent than our API functions.
    expression = "with (window._inspectorCommandLineAPI) { with (window) { " + expression + " } }";
    return evalFunction.call(object, expression);
}

Обновлено: Только что проверил источник Firebug, они цепочка 4 с утверждениями вместе для еще большего количества слоев. Псих!

const evalScript = "with (__win__.__scope__.vars) { with (__win__.__scope__.api) { with (__win__.__scope__.userVars) { with (__win__) {" +
    "try {" +
        "__win__.__scope__.callback(eval(__win__.__scope__.expr));" +
    "} catch (exc) {" +
        "__win__.__scope__.callback(exc, true);" +
    "}" +
"}}}}";

Форк CoffeeScript Коко имеет ключевое слово with, но он просто устанавливает this (также доступный для записи как @ в CoffeeScript / Coco) для целевого объекта внутри блока. Это устраняет двусмысленность и обеспечивает соответствие строгому режиму ES5:

with long.object.reference
  @a = 'foo'
  bar = @b

Для некоторых фрагментов короткого кода я хотел бы использовать тригонометрические функции, такие как sin, cos и т. д., В градусном режиме, а не в лучистом режиме. Для этого я использую объект AngularDegree:

AngularDegree = new function() {
this.CONV = Math.PI / 180;
this.sin = function(x) { return Math.sin( x * this.CONV ) };
this.cos = function(x) { return Math.cos( x * this.CONV ) };
this.tan = function(x) { return Math.tan( x * this.CONV ) };
this.asin = function(x) { return Math.asin( x ) / this.CONV };
this.acos = function(x) { return Math.acos( x ) / this.CONV };
this.atan = function(x) { return Math.atan( x ) / this.CONV };
this.atan2 = function(x,y) { return Math.atan2(x,y) / this.CONV };
};

Затем я могу использовать тригонометрические функции в градусном режиме без дополнительного языкового шума в блоке with:

function getAzimut(pol,pos) {
  ...
  var d = pos.lon - pol.lon;
  with(AngularDegree) {
    var z = atan2( sin(d), cos(pol.lat)*tan(pos.lat) - sin(pol.lat)*cos(d) );
    return z;
    }
  }

Это означает: я использую объект как набор функций, которые я включаю в ограниченной области кода для прямого доступа. Я считаю это полезным.

Использование with не рекомендуется и запрещено в строгом режиме ECMAScript 5. Рекомендуемая альтернатива - назначить объект, свойства которого вы хотите получить, временной переменной.

Источник: Mozilla.org

Вот хорошее применение with: добавление новых элементов в литерал объекта на основе значений, хранящихся в этом объекте. Вот пример, который я использовал сегодня:

У меня был набор возможных плиток (с отверстиями сверху, снизу, слева или справа), которые можно было использовать, и мне нужен был быстрый способ добавить список плиток, которые всегда будут размещаться и блокироваться в начале игры. . Я не хотел набирать types.tbr для каждого типа в списке, поэтому просто использовал with.

Tile.types = (function(t,l,b,r) {
  function j(a) { return a.join(' '); }
  // all possible types
  var types = { 
    br:  j(  [b,r]),
    lbr: j([l,b,r]),
    lb:  j([l,b]  ),  
    tbr: j([t,b,r]),
    tbl: j([t,b,l]),
    tlr: j([t,l,r]),
    tr:  j([t,r]  ),  
    tl:  j([t,l]  ),  
    locked: []
  };  
  // store starting (base/locked) tiles in types.locked
  with( types ) { locked = [ 
    br,  lbr, lbr, lb, 
    tbr, tbr, lbr, tbl,
    tbr, tlr, tbl, tbl,
    tr,  tlr, tlr, tl
  ] } 
  return types;
})("top","left","bottom","right");

Вы можете использовать with, чтобы избежать явного управления арностью при использовании require.js:

var modules = requirejs.declare([{
    'App' : 'app/app'
}]);

require(modules.paths(), function() { with (modules.resolve(arguments)) {
    App.run();
}});

Реализация requirejs.declare:

requirejs.declare = function(dependencyPairs) {
    var pair;
    var dependencyKeys = [];
    var dependencyValues = [];

    for (var i=0, n=dependencyPairs.length; i<n; i++) {
        pair = dependencyPairs[i];
        for (var key in dependencyPairs[i]) {
            dependencyKeys.push(key);
            dependencyValues.push(pair[key]);
            break;
        }
    };

    return {
        paths : function() {
            return dependencyValues;
        },
    
        resolve : function(args) {
            var modules = {};
            for (var i=0, n=args.length; i<n; i++) {
                modules[dependencyKeys[i]] = args[i];
            }
            return modules;
        }
    }   
}

Как отметил Энди Э в комментариях к ответу Shog9, это потенциально неожиданное поведение возникает при использовании with с литералом объекта:

for (var i = 0; i < 3; i++) {
  function toString() {
    return 'a';
  }
  with ({num: i}) {
    setTimeout(function() { console.info(num); }, 10);
    console.info(toString()); // prints "[object Object]"
  }
}

Не то чтобы неожиданное поведение не было отличительной чертой with.

Если вы действительно хотите использовать эту технику, по крайней мере используйте объект с нулевым прототипом.

function scope(o) {
  var ret = Object.create(null);
  if (typeof o !== 'object') return ret;
  Object.keys(o).forEach(function (key) {
    ret[key] = o[key];
  });
  return ret;
}

for (var i = 0; i < 3; i++) {
  function toString() {
    return 'a';
  }
  with (scope({num: i})) {
    setTimeout(function() { console.info(num); }, 10);
    console.info(toString()); // prints "a"
  }
}

Но это будет работать только в ES5 +. Также не используйте with.

Я работаю над проектом, который позволит пользователям загружать код для изменения поведения частей приложения. В этом сценарии я использовал предложение with, чтобы их код не изменял что-либо за пределами области действия, с которой я хочу, чтобы они возились. (Упрощенная) часть кода, которую я использую для этого:

// this code is only executed once
var localScope = {
    build: undefined,

    // this is where all of the values I want to hide go; the list is rather long
    window: undefined,
    console: undefined,
    ...
};
with(localScope) {
    build = function(userCode) {
        eval('var builtFunction = function(options) {' + userCode + '}');
        return builtFunction;
    }
}
var build = localScope.build;
delete localScope.build;

// this is how I use the build method
var userCode = 'return "Hello, World!";';
var userFunction = build(userCode);

Этот код гарантирует (отчасти), что пользовательский код не имеет доступа ни к каким объектам с глобальной областью видимости, таким как window, ни к какой-либо из моих локальных переменных через замыкание.

Как слово для мудрых, мне все еще нужно выполнять статические проверки кода для кода, отправленного пользователем, чтобы убедиться, что они не используют другие хитрые методы для доступа к глобальной области. Например, следующий пользовательский код получает прямой доступ к window:

test = function() {
     return this.window
};
return test();

Просто хотел добавить, что вы можете получить функциональность with () с красивым синтаксисом и без двусмысленности с вашим собственным умным методом ...

     //utility function
  function _with(context){
           var ctx=context;
           this.set=function(obj){
             for(x in obj){
                //should add hasOwnProperty(x) here
                ctx[x]=obj[x];
             }
       } 

       return this.set;          
 }

 //how calling it would look in code...

  _with(Hemisphere.Continent.Nation.Language.Dialect.Alphabet)({

      a:"letter a",
      b:"letter b",
      c:"letter c",
      d:"letter a",
      e:"letter b",
      f:"letter c",
     // continue through whole alphabet...

  });//look how readable I am!!!!

..или если вы В самом деле хотите использовать "with ()" без двусмысленности и без специального метода, заключите его в анонимную функцию и используйте .call

//imagine a deeply nested object 
//Hemisphere.Continent.Nation.Language.Dialect.Alphabet
(function(){
     with(Hemisphere.Continent.Nation.Language.Dialect.Alphabet){ 
         this.a = "letter a";
         this.b = "letter b";
         this.c = "letter c";
         this.d = "letter a";
         this.e = "letter b";
         this.f = "letter c";
         // continue through whole alphabet...
     }
}).call(Hemisphere.Continent.Nation.Language.Dialect.Alphabet)

Однако, как отмечали другие, это несколько бессмысленно, поскольку вы можете ...

 //imagine a deeply nested object Hemisphere.Continent.Nation.Language.Dialect.Alphabet
     var ltr=Hemisphere.Continent.Nation.Language.Dialect.Alphabet 
     ltr.a = "letter a";
     ltr.b = "letter b";
     ltr.c = "letter c";
     ltr.d = "letter a";
     ltr.e = "letter b";
     ltr.f = "letter c";
     // continue through whole alphabet...

Мой

switch(e.type) {
    case gapi.drive.realtime.ErrorType.TOKEN_REFRESH_REQUIRED: blah
    case gapi.drive.realtime.ErrorType.CLIENT_ERROR: blah
    case gapi.drive.realtime.ErrorType.NOT_FOUND: blah
}

сводится к

with(gapi.drive.realtime.ErrorType) {switch(e.type) {
    case TOKEN_REFRESH_REQUIRED: blah
    case CLIENT_ERROR: blah
    case NOT_FOUND: blah
}}

Можно ли доверять такому некачественному коду? Нет, мы видим, что его сделали абсолютно нечитаемым. Этот пример неоспоримо доказывает, что нет необходимости в with-statement, если я правильно понимаю удобочитаемость;)

использование оператора with с прокси-объектами

Недавно я хочу написать плагин для вавилон, который включает макросы. Я хотел бы иметь отдельное пространство имен переменных, в котором хранятся мои макропеременные, и я могу запускать свои макрокоды в этом пространстве. Кроме того, я хочу обнаруживать новые переменные, которые определены в кодах макросов (потому что это новые макросы).

Сначала я выбираю модуль vm, но я обнаружил, что глобальные переменные в модуле vm, такие как Array, Object и т. д., Отличаются от основной программы, и я не могу реализовать module и require, которые будут полностью совместимы с этими глобальными объектами (потому что я не могу реконструировать основные модули). В конце концов, я нахожу утверждение «с».

const runInContext = function(code, context) {
    context.global = context;
    const proxyOfContext = new Proxy(context, { has: () => true });
    let run = new Function(
        "proxyOfContext",
        `
            with(proxyOfContext){
                with(global){
                        ${code}
                }
            }
        `
    );
    return run(proxyOfContext);
};

Этот прокси-объект перехватывает поиск всех переменных и говорит: «Да, у меня есть эта переменная». и Если у прокси-объекта действительно нет этой переменной, покажите ее значение как undefined.

Таким образом, если какая-либо переменная определена в макросе code с помощью оператора var, я могу найти ее в объекте контекста (например, в модуле vm). Но переменные, определенные с помощью let или const, доступны только в это время и не будут сохранены в объекте контекста (модуль vm сохраняет их, но не раскрывает их).

Спектакль: Производительность этого метода лучше, чем vm.runInContext.

безопасность: если вы хотите запустить код в песочнице, это ни в коем случае не безопасно, и вы должны использовать модуль vm. Он предоставляет только новое пространство имен.