Pull to refresh

Comments 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 может показаться нелогичным относительно других языков программирования. Так что, я бы не назвал создание промежуточной переменной хаком на ровном месте.
UFO just landed and posted this here
Следующей на очереди обязана быть «JavaScript. The Good Parts»
UFO just landed and posted this here
У книжки такой плохой перевод, что глава названа «УжасТные вещи в JavaScript»?
UFO just landed and posted this here
Тогда ладно :). На будущее — если непонятно как писать, то проверяется элементарно — ужас (а не ужасТ)))
UFO just landed and posted this here
Ну я уж в такие дебри не лезу :). Понятно, читается нормально — и ладно.
Бедный, бедный «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!
Как вы это себе представляете? (в коде)
Да, под 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 — гл.; амер. модЕлировать, собирать из блоков
Но уж никак не модУлировать.
Спасибо, сам что-то не догадался посмотреть в оригинал (или поленился?..)
Наверное, имеется в виду «модулировать» — собирать из модулей.
UFO just landed and posted this here
«модулеризировать»
UFO just landed and posted this here
Потрясающе!
Огромнейшее спасибо за статью. Она очень помогла мне с пониманием этих отличий. К 2-м из трёх паттернов я уже и так пришёл методом проб и ошибок. Мануалы которые читал в своё время давали ответы на некоторые вопросы, но они не были настолько просты и одновременно глобальны как эта статья.

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

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

Articles