Как стать автором
Обновить

Комментарии 51

>> вините кривоватый дизайн JavaScript
Очень хочется попросить Барри не использовать языки программирования, которые он считает кривоватыми и тем более — не писать статьи для новичков о языках, которые он считает кривоватыми.

Было бы немного лучше, если бы он по крайней мере акцентировал внимание на том, что здесь очень много личного мнения. О вкусах, как говорят, не спорят. Но материал преподносится как борьба с каким-то объективным злом в то время, как имеет место обычное непонимание и это неприятно, это сеет ложные представления о языке среди новичков.
Не обижайтесь так на него, судя по блогу этот человек живет JavaScript'ом :)
Судя по блогу doctrina.org он только Fri 12 October 2012 написал первую статью про JavaScript, а живет он на Cryptography и Math.
да, это я не туда посмотрел. :)
все языки в чём-то кривоваты. что теперь, не программировать вовсе?) а писать статьи можно лишь об идеальных языках?
дизайн в этом месте и правда крив — вынуждает использовать хаки на ровном месте. ну вот какого лешего this начинает указывать в стратосферу, когда можно «по умолчанию» подставлять объект в контексте которого эта функция была создана?
Вы преувеличиваете. Сохранить ссылку на текущий контекст — ну разве «хак»? :) Просто надо понимать, что в JavaScript переменная this выполняет немного другую роль, нежели в других языках. Возьмем, например, небольшой код:
var MyClass = function(){
    this.a = 0;
    return {
        add: function(){
            this.a++;
        }
    }
}

var test = new MyClass ();
test.add();


Работать такой код правильно не будет, думаю ясно почему. Но стоит его немного модифицировать, как встанет на свои места.

var MyClass = function(){
    var self = this;
    self.a = 0;
    return {
        add: function(){
            self.a++;
        }
    }
}

var test = new MyClass ();
test.add();


Я к тому, что гибкость языка позволяет создавать совершенно разные конструкции, в которых поведение this может показаться нелогичным относительно других языков программирования. Так что, я бы не назвал создание промежуточной переменной хаком на ровном месте.
НЛО прилетело и опубликовало эту надпись здесь
Следующей на очереди обязана быть «JavaScript. The Good Parts»
НЛО прилетело и опубликовало эту надпись здесь
У книжки такой плохой перевод, что глава названа «УжасТные вещи в JavaScript»?
НЛО прилетело и опубликовало эту надпись здесь
Тогда ладно :). На будущее — если непонятно как писать, то проверяется элементарно — ужас (а не ужасТ)))
НЛО прилетело и опубликовало эту надпись здесь
Ну я уж в такие дебри не лезу :). Понятно, читается нормально — и ладно.
Бедный, бедный «this». Не видать тебе покоя.
Ждём статьи «3 паттерна вывода Hello Wrold» и «5 паттернов инкремента переменной»
И обязательный холиварчик на тему i++ vs i+=1
Я знаю. Надо определять движок и запускать самую быструю версию! Как-то так:

if (getEngine() == 'webkit') {
  i += 1;
} else if (getEngine() == 'trident') {
  i++;
} else if (getEngine() == 'gecko') {
  ++i;
}

Так мы сможем написать РЕАЛЬНО быстрое приложение.
Не не не, операторы сравнения тут не строгие, весь прирост производительности на нуль сводят:( Может, если свичом их перебирать — вообще летать будет. Хотя и это по разным движкам сравнивать нужно и дальше под все оптимизировать.
А теперь смертельный номер — запихнуть это дело в for (i=0; i<x; ???)
for(var i = 0, engine = getEngine(); i < x; engine == 'webkit'? i+= 1: engine == 'trident'? i++: engine == 'gecko'? ++i;);
кривоватый дизайн JavaScript
он не кривой, а другой. Функции имеют лексическую область видимости, а this — это спец переменная контекста вызова функции как и arguments, которая просто называется this и путает многих. Достаточно это понять и простить и все встанет на места.

Используя данный паттерн, this привязывается к global object. Это, несомненно, является ошибкой языка — постоянная привязка this к глобальному объекту может уничтожить его контекст.

По-моему главная ошибка автора в понимании языка.
И не совсем верно, на мой взгляд, в контексте javascript, называть методом, свойство объекта которому присвоена функция.
Заметьте, именно так, а не наоборот: «Функции являющиеся свойствами объекта».
Как писалось:
функции являются объектами первого класса

и их нужно воспринимать как самостоятельную боевую единицу.

Identifier resolution как раз и решает все проблемы с this.
Когда я начал изучать JS после C++, Java, мне тоже показалось не логичным и магическим все эти манипуляции с this, но стоит немного разобраться и это превращается в удобный и мощный инструмент, без которых уже и не привычно и сложно представить как то иначе. С мнением о кривоватости и бажности языка не согласен.

А еще из статьи я так и не понял каких особенностей нужно избегать, может просто применять по месту надо и всегда понимать что происходит?
В догонку напишите ешё про function_name.call.apply(… )

Ага) и var binded = func_name.bind(this); :)
о!
а это где работает?
и нафига тогда jQuery.proxy?
jQuery.proxy зло, нужно использовать нативный bind, а для IE fallback!
Как вы это себе представляете? (в коде)
А ну так бы и сказал Polyfill
Да, под fallback для IE я имел ввиду Polyfill
Так можно до бесконечности развивать эту идею:

var fn = function() {
    alert(1);
};

new fn.prototype.constructor;
// fn.prototype.constructor();
Раз про «кривоватый дизайн» автора статьи в комментах не заикнулся только ленивый, понаезжаю еще и на переводчика:
если функция возвращает число, цепочку, логическое выражение (true/false), null или undefined, return не сработает, a мы получим this
Строку, надеюсь?
К сожалению, существует несколько паттернов для вызова функций. О них не нужно быть в курсе. Их нужно зазубрить и понять...
Ломает мозг.

Ну и про this в strict mode и про bind в статье ничего.
this в strict mode
В Strict Mode объект this не будет корректироваться. Это возможно самая интересная часть Strict Mode и самая тяжелая(шокирующая) для разработчиков. Все знают, что если первый аргумент call или apply — null или undefined, то значение this выполняемой функции будет преобразование в глобальный объект (для браузеров это window). отсюда
>JavaScript, как и все современные языки, может модулировать логику внутри функций
Что значит «модулировать логику»? Это какой-то термин, или ошибка перевода? Ни разу не встречал этот глагол в контексте логики.
Есть же ссылка на оригинал:)
JavaScript (like all languages these days) has the ability to modularise logic in functions

тык
Хм… Всё-таки ошибка перевода тогда.
modularize — гл.; амер. модЕлировать, собирать из блоков
Но уж никак не модУлировать.
Спасибо, сам что-то не догадался посмотреть в оригинал (или поленился?..)
Наверное, имеется в виду «модулировать» — собирать из модулей.
НЛО прилетело и опубликовало эту надпись здесь
«модулеризировать»
НЛО прилетело и опубликовало эту надпись здесь
Потрясающе!
Огромнейшее спасибо за статью. Она очень помогла мне с пониманием этих отличий. К 2-м из трёх паттернов я уже и так пришёл методом проб и ошибок. Мануалы которые читал в своё время давали ответы на некоторые вопросы, но они не были настолько просты и одновременно глобальны как эта статья.

З.Ы. про call и aply отдельный респект. До этого времени я вообще не понимал зачем они в принципе нужны в js.
Парсер съел сарказм?
Здорово. Теперь это называется паттернами
Микропаттерны. Функциональные микропаттерны!
Я рад сообщить, что начиная с версии 1.8.5 JavaScript, Object.create является вполне работающим инструментом.

А с каких это пор у нас стал JavaScript версионным :)? Что это за реализация такая JavaScript
Может таки стандарт ECMAScript… нет? ECMAScript 5 или ECMAScript 6 (Harmony)
Что Вы наделали? Как же мне дальше с этим жить…
Спасибо, отличная статья! Помогла ноконец то расставити все точки над И. )
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории