diff --git a/scope & closures/ch2.md b/scope & closures/ch2.md index 604e8bd..41ea566 100644 --- a/scope & closures/ch2.md +++ b/scope & closures/ch2.md @@ -5,7 +5,7 @@ Есть две преобладающих модели того, как работает область видимости. Первая из них, безусловно самая распространенная, используется необъятным большинством языков программирования. Она называется **Лексическая область видимости** и мы изучим ее в деталях. Другая модель, которая все еще используется некоторыми языками (такими как скриптовый Bash, некоторые режимы в Perl и т.д.), называется **Динамическая область видимости**. -Динамическая область видимости рассматривается в приложении A. Я упоминаю ее здесь только чтобы показать контраст с лексической областью действия, которая является моделью области видимости, используемой в JavaScript. +Динамическая область видимости рассматривается в приложении A. Я упоминаю ее здесь только чтобы показать контраст с лексической областью видимости, которая является моделью области видимости, используемой в JavaScript. ## Время разбора на лексемы @@ -15,7 +15,7 @@ Определяя ее отчасти через саму себя, лексическая область видимости — это область видимости, которая определена во время разбора на лексемы. Иными словами, лексическая область видимости основана на том, где переменные и блоки области видимости были созданы вами во время написания и таким образом (в основном) навечно зафиксированы на момент, когда лексический анализатор обрабатывал ваш код. -**Примечание:** Совсем скоро мы увидим, что есть некоторые способы обмануть лексическую область действия, тем самым меняя ее после того, как лексический анализатор уже прошелся по ней, но к ним относятся неодобрительно. Считается лучшей практикой обращаться с лексической областью видимости как, по сути дела с чисто лексической и следовательно полностью относящейся к моменту написания кода по своей природе. +**Примечание:** Совсем скоро мы увидим, что есть некоторые способы обмануть лексическую область видимости, тем самым меняя ее после того, как лексический анализатор уже прошелся по ней, но к ним относятся неодобрительно. Считается лучшей практикой обращаться с лексической областью видимости как, по сути дела с чисто лексической и следовательно полностью относящейся к моменту написания кода по своей природе. Давайте рассмотрим этот код: @@ -190,7 +190,7 @@ console.log( a ); // 2 — Упс, утекшая глобальная пере **Примечание:** Даже если блок `with` трактует объект как лексическую область видимости, обычное объявление `var` внутри этого блока `with` не будет входить в область этого блока `with`, а вместо этого будет в области видимости функции, содержащей этот блок. -В то время как функция `eval(..)` может менять существующую лексическую область видимости, если она принимает строку кода с одним или более объявлениями в ней, то оператор `with` на самом деле создает **полностью новую лексическую область действия** на ровном месте из объекта, который вы ему передаете. +В то время как функция `eval(..)` может менять существующую лексическую область видимости, если она принимает строку кода с одним или более объявлениями в ней, то оператор `with` на самом деле создает **полностью новую лексическую область видимости** на ровном месте из объекта, который вы ему передаете. Таким образом мы поняли, что "область видимости", объявленная оператором `with` когда мы передали `o1`, была `o1` и что у этой "области видимости" есть "идентификатор", который соответствует свойству `o1.a`. Но когда мы использовали `o2` как "область видимости", у нее не было такого "идентификатора" `a` и поэтому сработали обычные правила поиска LHS-идентификатора (см. главу 1). diff --git a/scope & closures/ch3.md b/scope & closures/ch3.md index c7b76d0..df93678 100644 --- a/scope & closures/ch3.md +++ b/scope & closures/ch3.md @@ -101,7 +101,7 @@ doSomething( 2 ); // 15 ### Предотвращение коллизий -Еще одно преимущество "скрытия" переменных и функций внутри области действия — чтобы избежать неумышленных коллизий между двумя идентификаторами с одним и тем же именем, но с разным целевым использованием. Коллизии часто приводят к неумышленной перезаписи значений. +Еще одно преимущество "скрытия" переменных и функций внутри области видимости — чтобы избежать неумышленных коллизий между двумя идентификаторами с одним и тем же именем, но с разным целевым использованием. Коллизии часто приводят к неумышленной перезаписи значений. Например: @@ -364,7 +364,7 @@ for (var i=0; i<10; i++) { Зачем загрязнять всю область видимости функции переменной `i`, которая будет использоваться (или только *следует*, по меньшей мере) в цикле for-loop? -Но более важно, что разработчики могут предпочесть *проверить* себя на предмет случайного (пере)использования переменных снаружи от их предполагаемой области действия, как например получить ошибку о неизвестной переменной, если вы пытаетесь использовать ее не в том месте. Блочная область видимости (если бы она была возможна) для переменной `i` сделала бы `i` доступной только для цикла for-loop, приводя к ошибке, если к `i` осуществляется доступ в другом месте функции. Это помогает убедиться, что переменные не будут переиспользованы в нечетких или труднообслуживаемых сценариях. +Но более важно, что разработчики могут предпочесть *проверить* себя на предмет случайного (пере)использования переменных снаружи от их предполагаемой области видимости, как например получить ошибку о неизвестной переменной, если вы пытаетесь использовать ее не в том месте. Блочная область видимости (если бы она была возможна) для переменной `i` сделала бы `i` доступной только для цикла for-loop, приводя к ошибке, если к `i` осуществляется доступ в другом месте функции. Это помогает убедиться, что переменные не будут переиспользованы в нечетких или труднообслуживаемых сценариях. Но, печальная реальность состоит в том, что, на первый взгляд, в JavaScript нет возможности блочной области видимости. diff --git a/up & going/ch3.md b/up & going/ch3.md index 040a9c4..72aa1db 100644 --- a/up & going/ch3.md +++ b/up & going/ch3.md @@ -9,15 +9,15 @@ Я использую эту последнюю главу, чтобы кратко подвести итог того, чего ждать от оставшихся книг серии и как наиболее эффективно приняться за постройку основы обучения JS держа в своих руках *YDKJS*. -## Область действия и замыкания +## Область видимости и замыкания -Наверное одна из самых фундаментальных вещей, которые понадобятся вам, чтобы быстрее подобраться к этим терминам — это как именно создание области действия переменных на самом деле работает в JavaScript. Недостаточно иметь анекдотичные расплывчатые *представления* об области действия. +Наверное одна из самых фундаментальных вещей, которые понадобятся вам, чтобы быстрее подобраться к этим терминам — это как именно создание области видимости переменных на самом деле работает в JavaScript. Недостаточно иметь анекдотичные расплывчатые *представления* об области действия. -Книга *Область действия и замыкания* начинается с развенчания общего ложного представления, что JS — "интерпретируемый язык" и потому не компилируется. А вот и нет! +Книга *Область видимости и замыкания* начинается с развенчания общего ложного представления, что JS — "интерпретируемый язык" и потому не компилируется. А вот и нет! -Движок JS компилирует ваш код прямо перед (а иногда и во время!) выполнением. Поэтому вы пойдете путем более глубокого понимания подхода компилятора к вашему коду, чтобы понять как он находит и разбирается с объявлениями переменных и функций. Попутно, мы посмотрим типичную схему JS по управлению областью действия переменных, "Всплытие (hoisting)." +Движок JS компилирует ваш код прямо перед (а иногда и во время!) выполнением. Поэтому вы пойдете путем более глубокого понимания подхода компилятора к вашему коду, чтобы понять как он находит и разбирается с объявлениями переменных и функций. Попутно, мы посмотрим типичную схему JS по управлению областью видимости переменных, "Всплытие (hoisting)." -Именно это критическое понимание "лексической области действия" — то, на чем мы потом будет основывать наше исследование замыкания в последней главе этой книги. Замыкание — возможно, единственное самое важное понятие во всем JS, но если вы сперва не разберетесь плотно как работает область действия, замыкание скорее всего останется вне вашего понимания. +Именно это критическое понимание "лексической области видимости" — то, на чем мы потом будет основывать наше исследование замыкания в последней главе этой книги. Замыкание — возможно, единственное самое важное понятие во всем JS, но если вы сперва не разберетесь плотно как работает область видимости, замыкание скорее всего останется вне вашего понимания. Одно важное применение замыкания — это модульный шаблон, который мы уже кратко представили в этой книге в главе 2. Модульный шаблон, возможно, самый преобладающий шаблон организации кода во всем JavaScript; его глубокое понимание должно быть одним из самых высоких ваших приоритетов. @@ -27,7 +27,7 @@ Ключевое слово `this` динамически привязывается основываясь на том как выполняется функция и выясняется, что есть четыре простых правила, чтобы понять и полностью определить привязку `this`. -Тесно связан с ключевым словом `this` механизм прототипов объектов, который является цепочкой поисков свойств, похожих на то, как обнаруживаются переменные в лексической области действия. Но при погружении в прототипы есть другой большой промах с JS: идея эмуляции (замены) классов и так называемое наследование через прототипы. +Тесно связан с ключевым словом `this` механизм прототипов объектов, который является цепочкой поисков свойств, похожих на то, как обнаруживаются переменные в лексической области видимости. Но при погружении в прототипы есть другой большой промах с JS: идея эмуляции (замены) классов и так называемое наследование через прототипы. К сожалению, желание привнести мышление шаблоном проектирования классов и наследования в JavaScript — это просто наихудшая вещь, которую вы могли бы сделать, несмотря на то, что синтаксис может вводить вас в заблуждение, что есть что-то подобное классам, в действительности механизм прототипов фундаментально противоположен по своему поведению. @@ -87,7 +87,7 @@ Поскольку ES6 почти готов на момент написания этих строк, *ES6 и за его пределами* начинается с того, что делится практическими вещами из пространства ES6 в нескольких ключевых категориях, включая новый синтаксис, новые структуры данных (коллекции) и новые возможности обработки и API. Мы рассмотрим каждую из этих новых возможностей ES6 на различных уровнях детализации, включая рассмотрение деталей, которые затрагиваются в других книгах серии. -Вот некоторые захватывающие вещи в ES6, про которые вы будете с нетерпением ждать, чтобы прочесть: деструктурирование (destructuring), значения параметров по умолчанию, символы, сокращенные методы (concise methods), вычисляемые свойства, стрелочные функции (arrow functions), блочная область действия, обещания (promises), генераторы, итераторы, модули, прокси, слабосвязанные коллекции ключ-значение (weakmaps) и многое, многое другое! Ну и ну, ES6 производит огромное впечатление! +Вот некоторые захватывающие вещи в ES6, про которые вы будете с нетерпением ждать, чтобы прочесть: деструктурирование (destructuring), значения параметров по умолчанию, символы, сокращенные методы (concise methods), вычисляемые свойства, стрелочные функции (arrow functions), блочная область видимости, обещания (promises), генераторы, итераторы, модули, прокси, слабосвязанные коллекции ключ-значение (weakmaps) и многое, многое другое! Ну и ну, ES6 производит огромное впечатление! Первая часть книги — это дорожная карта по всем вещам, которые вам необходимо изучить, чтобы подготовиться к новому и улучшенному JavaScript, на котором вы будете писать и который будете исследовать в течение следующей пары лет.