Статья о JavaScript

[Zeroglif]

В JavaScript нет оператора, позволяющего проверить, относится ли метод или атрибут непосредственно к объекту

относится ли свойство

Оператор == перед проверкой на равенство осуществляет преобразование типов

Зависит от сравниваемых значений. null == undefined -> нет конвертации

Функции, как и любые другие объекты, могут иметь поля и методы.

Полей, слотов и проч. нет, или просто свойства или свойства и методы

с помощью псевдо-массива arguments

объект это, если приставка "псевдо" характеризует нечто особенное, то придётся описывать реализацию этого объекта в той же опере, где это совсем не псевдо, но лучше ограничиться термином из стандарта (ES 10.1.8)

Определяет, является ли данный объект прототипом объекта-аргумента

находится ли объект в цепи прототипов

На сегодняшний день поддержку JavaScript обеспечивают современные версии всех наиболее часто используемых браузеров. При этом в полной мере ядро языка поддерживается браузерами[96]:

* Mozilla Firefox версии 2 и выше,
* Opera версии 9 и выше.

Где IE? Внесите IE в список!!!, наличие Оперы с кучей багов и отложенной реализацией EcmaScript вкупе с вечным отсутствием документации выглядит анекдотом при отсутствии IE с его давным давно сделанной реализацией. Отсылка на смешную матрицу, где выбраны 2 бага реализации ES в IE и нет вообще ни одного бага в отношении FF, которых куча, не может считаться объективной. В настоящее время у ВСЕХ!!! браузеров есть недочёты (недореализация ES или определённые баги). Выталкивать из списка IE за такую ерунду, как trailing comma в массивах... хм... ;-)

С момента публикации статьи ситуация улучшилась[102]. Особенно в отношении англоязычных источников.

Ухудшилась ситуация.

Оператор + является единственным арифметическим операторов в языке, который перегружен для строковых аргументов. Таким образом, если оба его операнда являются числами, он вычисляет их сумму, но если хотя бы один из операндов — строка, + действует как конкатенатор.

А если нет строк в операндах, но и чисел тоже нет, или одно число...? Это я к тому, что для вычисления суммы необязательно наличие операндов-чисел.

идентификаторы функций являются переменными, хранящими ссылку на функцию

Можно было бы уточнить, что стандарт этого (кас. ссылок) не раскрывает вообще. Если вам нужны ссылки на цитаты Брендана по этому поводу, то они есть в соседней теме, где обсуждалось by-value. Идентификаторы функций не являются переменными в смысле EcmaScript.

При объявлении функции последовательность областей видимости, относящихся к вложенным функциям сохраняется как составляющая состояния функции. То есть в процессе выполнения JavaScript-программы функции, обладающие доступом к локальным переменным объемлющих функций, сохраняют такой доступ на протяжении всего выполнения программы

Двусмысленный текст получился. При объявлении функции вложенных функций "как бы нет", поэтому области видимости к ним не относятся.

var uniqueId = (function() {
var id = 0;
return function() { return id++; };
})();

Скобки вокруг функции не нужны в этом случае. И без скобок выражение.

typeof inc === 'number'

Результатом 'typeof' будет строка. Сравнивая строку со строкой, совершенно не нужно использовать строгое сравнение, сравниваются значения одного типа изначально. Одно значение вы задали руками, второе значение вписано в алгоритм языка.

Каждый объект в языке имеет следующие свойства: constructor...

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

Для обеспечения кросс-браузерности и высокого уровня абстракции при разработке веб-приложений используются библиотеки JavaScript. Они представляют собой набор многократно используемых объектов и функций.

Абстракции - да, кросс-браузерности - нет, подавляющее большинство фреймворков (если не все) кроссбразерными не были не минуту своей жизни. ;-)

JavaScript использует прототипный подход (где нет классов, а объект — просто хеш);

В javascript объект - это не хэш... или расшифровывайте тогда, что такое хэш, чтобы не путали те, у кого в голове соответствующее представление. Объект в javascript наследует, "не пуст" и проч...

Всё. Дочитал. Хорошая статья - обзорная, сухо и достаточно точно написанная. Спасибо за труд.

[Zeroglif]

http://www.davidflanagan.com/ - сайт/блог автора единственной вменяемой книги по js.

[B~Vladi]

Zeroglif,

сайт/блог автора единственной вменяемой книги по js.

Не пора ли вместе с Dmitry A. Soshnikov и Илья Кантор свою написать?!... А то все стонут, что книг норм нет, а те что норм - перевод из-за бугра?!

[Zeroglif]

Да в наше время и без книжек можно прожить. ;-)

[Plest]

Dmitry A. Soshnikov,
Спасибо.
По Вашим замечаниям мне осталось поправить части статьи о следующих вещах:
функциональный аргумент,
constructor,
конструктор.

Zeroglif,
Спасибо.
По Вашим замечаниям мне осталось поправить следующие вещи:
- раздел по истории языка (в книгах не нашёл подробного освещения, однако нашёл пресс-релизы, которые Вы упоминаете),
- области видимости,
- constructor.
=== в сниппетах кода хочу оставить по похожим причинам, что и необязательные точки с запятой: оно, скорее, добро чем зло: взять те же рекомендации Крокфорда.

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

Хотел спросить вашего мнения вот по какому вопросу. В русскоязычной Википедии есть довольно бледно выглядящая статья ECMAScript. Есть смысл перенести туда раздел Ядро из статьи JavaScript, оставив первый абзац и ссылку? Смущает вот что:
- в литературе, в основном, фигурирует JavaScript, когда речь, на самом деле идёт об ECMAScript и это может внести путаницу у читателей;
- синтаксис языка — довольно важная его часть. Есть ли смысл заставлять читателя делать лишний клик.
Может быть, имеет смысл перенести не всё, а какую-то часть? Или что-то продублировать? Мне подходящего варианта в голову не приходит, рецензенты по этому поводу тоже пока молчат.

В англоязычной Википедии поступили следующим образом: выделили синтаксис языка в отдельную статью, а затем пришли к выводу, что текст неэнциклопедичен и должен быть перенесён в Wikibooks.

[Zeroglif]

оно, скорее, добро чем зло

Тут дело вот в чём - строгое сравнение может иметь смысл, если тип значений операндов вами не контролируется (неизвестен заранее, возможны варианты). В вашем случае типы заранее известны, алгоритм сравнения равных типов тоже известен. Лично мне, пуристу, лишнее "равно" режет глаз и говорит или о принципиальном (ставить всегда и везде) последователе рекомендаций Крокфорда, или говорит о не понимании программистом работы оператора 'typeof'. Одно из двух. Подчеркну, что до этих рекомендаций (авторских) и до повального использования во фреймворках строгое сравнение было исключительным и использовалось только по назначению, учитывая и алгоритм, и историю оператора с его более поздним внедрением в язык и багами на ранней стадии. Строгое сравнение внешне подчёркивало, что в этой точке нужен контроль - типы неизвестны, требуется выброс 'false' при их неравенстве. Это похоже на то, где вы обрамили функцию скобками, хотя это совершенно не требуется.

Есть смысл перенести туда раздел Ядро из статьи JavaScript, оставив первый абзац и ссылку?

Есть смысл. С одной стороны, термин JavaScript(тм) размыт и используется повсеместно, заменяя собой стразу несколько реализаций и сам стандарт. С другой стороны, для вики истина должна быть немного дороже, чем читатели вики. ;-) Терминологическая путаница разбиралась в своё время в c.l.j, пришли к выводу, что если в тексте не акцентируется конкретная реализация, то речь идёт о принципах и алгоритмах ES или о любой реализации ES в общем смысле:

Richard Cornford:
It has long since been widely agreed that 'javascript' is an appropriate term to use when talking of all ECMAScript implementations, so JavaScript(tm) and JScript (and KScript, DScript or whatever) can be used to talk about specific implementations. The usage of 'javascript' is now common and well understood.
http://groups.google.com/group/comp....6b9c3bfa268d43

Michael Winter:
JavaScript (capital J, capital S) refers to a specific ECMAScript implementation. Javascript (capital J, or all lower case) is conventionally used, at least in c.l.javascript, to refer to ECMAScript implementations in general.
http://groups.google.com/group/alt.h...87d7bba18eb59e

Jim Ley:
Javascript without the capital S is also commonly used to refer to all ECMAScript languages, having JavaScript reserved for Netscapes implementation. So you say javascript, but that's just a name in the registry which is aliased to JScript.
http://groups.google.com/group/comp....f3722f49894f03

John G Harris:
Actually both JavaScript and JScript are registered trade marks. You are not allowed to use either word to cover both language variants. That's why "javascript" is a reasonable word to use when you are not talking about a particular release of a particular company's product.
http://groups.google.com/group/comp....154ce65d596fae

John G Harris:
ECMAScript (capital S says ECMA) is only the core language. It doesn't include i/o facilities such as Alert and file access. The advantage of "javascript" is that the lack of capital letters suggests that it's not restricted to the products of one company or organisation.
http://groups.google.co.uk/group/com...0e481801dab3b6

Ядро должно быть перенесено в отдельную статью просто по той причине, что иначе блок про ядро нужно дублировать в статье про тот же JScript(тм), язык совершенно независимый от JavaScript(тм), имеющий собственное название и кучу собственных фич. Не менее достойный претендент на полное описание.

Что касается неэнциклопедичности - ничего не могу чказать, я не знаю этих ваших принципов. ;-)

[Zeroglif]

И ещё. Скриптовые языки отдельных производителей не равны EcmaScript, о чём вы правильно упоминаете в разделе про структуру. JavaScript, а потом и JScript были предтечей, базой для выработки и написания стандарта. Оформившись в независимую сущность, стандарт стал требовать своего соблюдения. В этом смысле скриптовый язык - это не реализация EcmaScript только лишь, а язык (JavaScript, JScript), в котором реализованы синтаксис, семантика, принципы и алгоритмы другого языка (ES). Если это реализовано правильно, то скриптовый язык получает медаль: "Conforming implementation of ECMAScript".

В общем, я голосую за выделение ядра в отдельную статью. И за ремарку в статье про JavaScript о смешении терминологии.

Удачи вам.

[Dmitry A. Soshnikov]

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

Функциональный аргумент - это термин используемый в функциональных языках и означающий, что аргументом некой функции, является так же - функция. Функция, принимающая функциональный аргумент, называется функционалом (в математике - оператор).

Функции же, возвращающие другие функции, называются функции с функциональным значением.

Я затрагивал эти определения в статье о замыканиях в ES.

Функциональный аргумент (сокращённо, "Фурарг", "Funarg") - это одна из "проблем" стековой организации локальных переменных. Решением этой проблемы и являются замыкания, которые запоминают весь лексический контекст ещё на этапе создания. Соответственно, локальные переменные хранятся уже не в стеке, а в "куче" (heap).

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

Поскольку в ES все функции являются замыканиями, то теоретически, термин функциональный аргумент подошёл бы больше. Хотя, и коллбэк - тоже вписывается.

Двояко, на самом деле. Возможно даже, функциональный аргумент - это частный случай коллбэка, а не наоборот, как я отмечал выше, но я, опять же, имел в виду относительно ES.

Поэтому можно оставить и коллбэк, сильной принципиальной разницы нет. К тому же, коллбэк, действительно, более привычное и распространённое понимание передачи кода параметров в функцию.

constructor

Свойство constructor привилегированно лишь двумя моментами: (1) оно автоматом создаётся при создании объектов-функций и записывается в свойство функции prototype и (2) свойство constructor в этом случае получает {DontEnum}, т.е. не выводится в for...in.

За исключением того, что порождённые от функции-конструктора объекты, будут находить это свойство в своём прототипе (ведь оно было добавлено в Функция.prototype при создании Функции), ничего примечательного больше с этим свойством не связано. Его можно свободно удалить или изменить.

Т.е. основной момент, что свойство constructor - это свойство прототипа объекта, но не родное свойство. Соответственно, утверждение, что все объекты при порождение получают свойство constructor - неверное. Ни один из объектов не получает свойство constructor при порождении (кроме как объекта, являющегося свойством prototype фунцкии), но объекты наследуют это свойство из своего прототипа, поскольку прототип объектов - [[Prototype]] был установлен из свойства функции prototype (или же из Object.prototype, если на момент порождения Функция.prototype не являлся объектом).

конструктор

Конструктор в ES - это любая функция; функция любого типа: будь то, декларация функции (Function Declaration), функция-выражение (Function Expression) или функция, созданная конструктором Function.

Если разобрать глубже, то код самой функции является инициализирующим, поскольку за создание объекта отвечает на сама функция, а её внутреннее свойство [[Construct]].

[[Construct]] - это общий конструктор для всех объектов. Когда создаются функции, все они получают внутреннее свойство [[Construct]].

Оператор new, соответственно, вызывает метод [[Construct]], который и создаёт объект. И уже затем, сам [[Construct]], вызывает функцию в контексте вновь созданного объекта, т.е. делает что вроде: Функция.apply(созданныйОбъек� �, arguments);.

Более подробно о конструкторе - в седьмой части. Там же - алгоритм создания объектов.

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

Для Википедии, поскольку там должно быть описание не чисто теоретико-сухое и не чересчур углублённое, а - для точного, но основного понимания, может быть следующим:

Конструктор в ES- это (любая) функция, являющаяся шаблоном для порождаемых объектов. Применённая к оператору new, она создаёт объект и инициализирует его, будучи вызванной в контексте созданного объекта. За непосредственное выделение памяти и создание объекта, отвечает её внутренний метод [[Construct]], который является стандартным конструктором для всех объектов и записывается в каждую функцию при её создании. Не обязательно в таком виде, но с этой сутью.

Хотя, можно и срезать дебри про [[Construct]] и вынести чуть ниже. Т.е. сделать основное описание, что - это функция, создающая и инициализирующая объект посредством this (у вас сейчас примерно так и написано). И написать, что подробное определение смотрите чуть ниже (кому интересно).