Статья о JavaScript
 

Помогите с вычиткой статьи Википедии о JavaScript (http://ru.wikipedia.org/wiki/JavaScript)?
О чём ещё написать? Что переработать?

Интроспекция есть, но тип объекта не меняется динамически за счёт изменения прототипа. Более того, прототип объекта не может быть изменён (полностью на новый объект) после создания объекта. Исключение составляют некоторые реализации - типа __proto__ в Gecko.

Это, действительно, отсебятина Флэнагана, и к ES не имеет отношения. В ES null и undefined - это значения примитивных типов.

Объявление переменных

Переменные объявляются исключительно с ключевым словом var. Без var - создаётся лишь свойство глобального объекта, но не переменная. Как было правильно замечено, переменные нельзя удалить. Но опять же, терминология "долговременные" - это отсебятина Флэнагана. Правильная терминология: переменные получают внутреннее свойство {DontDelete} и, соответвественно, не могут быть удалены посредством оператора delete.

Более того, в контексте eval-а, var-ы, всё-таки, могут быть удалены, поскольку, в этом контексте им не выставляется {DontDelete}.

И точка, и скобки - это выражение доступа к свойству.

На протяжении всего оприсания функций, вы говорите о функции-выражении (Function Expression). Функции-инструкции (Function Statement) - это расширение Gecko для описания функций внутри блоков.

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

Только, если она не сохранена (возвращена) и, соответственно, её [[Scope]] вместе с ней.

Автоматом, только функции получают свойство constructor, и то, оно потом может быть удалено.

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

Про DOM почитал поверхностно.

http://javascript.ru/ecmascript-in-detail (возможно, будет перевод на английский).

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

Еще есть специальное значение Infinity.

Dmitry A. Soshnikov: потрясающе. Спасибо большое. Привожу в соответствие с Вашими замечаниями. Начал с объявлений переменных: там смысл сильно меняется. Ни в одной книге из просмотренных не нашёл то, о чём Вы пишите в Тонкостях ECMA-262-3. Часть 2. Объект переменных. Однако со спецификацией и здравым смыслом материал статьи очень хорошо согласуется.

Zeroglif: Спасибо

Octane: Мм. Смысл фразы в том, что Number в JavaScript — это практически то же самое, что определяется стандартом IEEE 754-2008 за исключением небольшого отличия в отношении NaN. И в отношении специального значения Infinity всё в полном соответствии с IEEE 754-2008..

Plest, рад помочь.

По поводу ООП, в разделе литературы, вы в первую очередь приводите и рекомендуете книги Дж.Резига; однако, некоторая его информация также местами является весьма поверхностной (а иногда, и отсебятиной), слабо стыкующейся с ES.

Объективно, наиболее полной и точной информацией по ООП в JS на сегодня в .ru-нете (и не только в ru-нете, по мнению некоторых англоговорящих коллег) является эта статья, она будет переведена в первую очередь.

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

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

У Резига есть ошибки, конечно. Но, по-моему, из печатного на русском лучше его книги, а также «Подробных руководств» Флэнагана и Макфарланда, книг по JavaScript сейчас просто нет. Здесь хвалят книгу Гудмана. По-моему, из её тысячи страниц полезная информация есть страниц пятьдесят.

По поводу механики ООП в JavaScript IMHO книге Стояна Стефанова нет равных.

Статья ваша, вам решать ;) Да, среди списка книг ссылка на web-log выбивается. Однако, в отличие от статичной книги, блог - это более живая информация, она может меняться, дополняться, корректироваться согласно времени (и благодаря комментариям компетентных коллег).

Как вариант, можно ниже где-нибудь в ссылках оставить, а не в списке литературы. Только тогда, получается, не в разделе " Блоги известных авторов книг ", поскольку я, всё-таки, книг (пока) не написал и не знаю, есть ли большой смысл.

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

Я, к сожалению, подробно не читал эту книгу, мельком по диагонали пролистывал. Там тоже есть недочёты. Например, он пишет сначала, что каждый объект имеет свойство .constructor, которое записывается в объект при создании, что, естественно, неверно:

Далее, показывается (невзначай), что .constructor, всё-таки, принадлежит прототипу (хотя, я не знаю, может, это всё ещё следствие того, что все объекты, "получают" свойство .constructor):

Последний код - явно полная белиберда. Показана рекурсивная ссылка функции на саму себя и снова на свойство prototype. Настоящая же цепь прототипов - она неявная (implicit) и прототип объекта - это внутреннее свойство [[Prototype]], которое недоступно напрямую и не может быть изменено (за исключением, опять же, расширений типа __proto__).

Также, цепь прототипов заканчивается не на Object, как пишется (и даже не на Object.prototype), а на Object.prototype.[[Prototype]], который и будет равен null.

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

Ну, я лично ни с кем не соревнуюсь ;) Я просто пишу то, что знаю, передавая знания тем, кому это интересно.

Быстро по истории:

Под именем LiveScript язык появился летом-осенью 1995 года на стадии разработки Netscape Navigator 2.0. Уже во второй бете NN2.0b2 язык появился (пока не официально) под своим нынешним именем JavaScript. Официальная презентация JavaScript состоялась 4 декабря 1995 года, звучал анонс так: "NETSCAPE AND SUN ANNOUNCE JAVASCRIPT(TM), THE OPEN, CROSS-PLATFORM OBJECT SCRIPTING LANGUAGE FOR ENTERPRISE NETWORKS AND THE INTERNET".

Термин "Mocha" использовался только узко среди разработчиков, но не выходил в свет в отличие от LiveScript и последующего JavaScript.
Microsoft официально анонсировала свой язык 29 мая 1996 года вместе с Internet Explorer 3.0 Beta под именем ActiveX Script. Следующая официальная презентация языка уже под его нынешним именем JScript состоялась 18 июля 1996 года, звучал анонс так: "Microsoft Corp. (Nasdaq: MSFT) today announced it would deliver binary and source reference implementations of the scripting engines for Visual Basic(R), Scripting Edition and JScript, the Microsoft(R) open implementation of the JavaScript(TM) language." Справедливости ради надо сказать, что Microsoft не долго отставала от Netscape в части создания скриптового языка, уже зимой 1996 года появились первые упоминания о реализации движка, который в разных источниках обозначался, как OLE Scripting, Scripting Host, ActiveX Scripting, ActiveX Script.

Что книжка стоянова, что книжка ресига - полное г. хотя бы с (полу)академической точки зрения. Назовите мне 10 страниц наугад и мы проверим качество. Неужели нельзя обойтись без того, чтобы тащить это в википедию. Обидно за предмет. ;-)

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

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

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

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

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

Где IE? Внесите IE в список!!!, наличие Оперы с кучей багов и отложенной реализацией EcmaScript вкупе с вечным отсутствием документации выглядит анекдотом при отсутствии IE с его давным давно сделанной реализацией. Отсылка на смешную матрицу, где выбраны 2 бага реализации ES в IE и нет вообще ни одного бага в отношении FF, которых куча, не может считаться объективной. В настоящее время у ВСЕХ!!! браузеров есть недочёты (недореализация ES или определённые баги). Выталкивать из списка IE за такую ерунду, как trailing comma в массивах... хм... ;-)
Ухудшилась ситуация.
А если нет строк в операндах, но и чисел тоже нет, или одно число...? Это я к тому, что для вычисления суммы необязательно наличие операндов-чисел.
Можно было бы уточнить, что стандарт этого (кас. ссылок) не раскрывает вообще. Если вам нужны ссылки на цитаты Брендана по этому поводу, то они есть в соседней теме, где обсуждалось by-value. Идентификаторы функций не являются переменными в смысле EcmaScript.
Двусмысленный текст получился. При объявлении функции вложенных функций "как бы нет", поэтому области видимости к ним не относятся.
Скобки вокруг функции не нужны в этом случае. И без скобок выражение.
Результатом 'typeof' будет строка. Сравнивая строку со строкой, совершенно не нужно использовать строгое сравнение, сравниваются значения одного типа изначально. Одно значение вы задали руками, второе значение вписано в алгоритм языка.
Обязательно нужен акцент на то, что это и другие там же перечисленные свойства являются наследуемыми, а не собственными свойствами объекта.
Абстракции - да, кросс-браузерности - нет, подавляющее большинство фреймворков (если не все) кроссбразерными не были не минуту своей жизни. ;-)
В javascript объект - это не хэш... или расшифровывайте тогда, что такое хэш, чтобы не путали те, у кого в голове соответствующее представление. Объект в javascript наследует, "не пуст" и проч...

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

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

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

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

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

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

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

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

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

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

Есть смысл. С одной стороны, термин 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(тм), имеющий собственное название и кучу собственных фич. Не менее достойный претендент на полное описание.

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

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

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

Удачи вам.

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

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

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

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

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

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

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

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

Свойство 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 (у вас сейчас примерно так и написано). И написать, что подробное определение смотрите чуть ниже (кому интересно).