[Dmitry A. Soshnikov]

а python разве прототипный?

Ага. Как, по большому счету, и JavaScript -- классовый (в нем возможность классового реюза и классовой генерации проявлена в полной мере). Но помимо возможности программировать в классовом стиле, JS, естественно, в основе -- делегирующий (прототипный) язык, т.е. поддерживающий неклассифицированный (или, что я называю, хаотичный) code reuse. Но, я думаю, здесь смысла нет рассказывать подробно.

Как Python и JS связаны с прототипами и классами можно хорошо видеть на скомпилированном коде класса (справа в примере по ссылке) CoffeeScript.

Поскольку, еще раз, класс -- это не какое-то ключевое слово class в языке, это не возможность объявлять классы этим словом; класс -- это возможность классифицировать (а как это делается -- с ключевым ли словом class или function -- это дело десятое уже). И в JS эта возможность была всегда. Правда, без "сахара". В Python (и Coffee) -- с сахаром. Вот и в JS такой же сахар будет.

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

хм, а coffeescript используется в реальных проектах?

Да, конечно же (поищи по Github). У меня тоже есть небольшой проект -- SchemeOnCoffee (тест online).

Но непонятно, о каком раннем связывании идет речь, почему оно не возможно и как это влияет на классы

Тут речь про старые классы из ES4. Сейчас обсуждаются уже "другие" классы.

По поводу раннего связывания -- да, будет такое, и будет касаться всех binding'ов (переменных/функций/модулей и т.д.). Это означает, что, например, ошибки присваивания неопределенной переменной a = 10 будут ловиться еще на этапе компиляции. Глобальный объект будет удален из списка scope chain. Будет глобальный модуль, куда по-дефолту импортированы все глобальные байндинги. Технически это означает, что нельзя динамически (кроме спец. мета-методов), по случайности, создать, например, глобальную переменную -- только import'ом из какого-нибудь другого модуля (а это значит, что опять это известно на этапе компиляции). Но это длинная тема, парой слов не опишешь.

Если классы будут статическими, то раннее связывание поможет, естественно эффективней выделить память (и привязать this сразу однозначно). Но сейчас про статические классы я не слышал (пока только "сахар" обсуждается). Я вообще против только статических классов. Один из вариантов сахара, который я предлагал -- такой.

И кстати, о "замораживании" объектов сейчас речь не идет в контексте классов?

Есть такой участник TC-39, Mark Miller (Google). У него все примеры -- с Object.freeze и с const Но как отмечал Brendan, встроенные конструкторы/классы JS станут статическими только через его труп Нет, пока не говориться, что классы будут замороженными по-дефолту. Но, возможно. Мне бы не хотелось (если будет решаться, я выскажусь против).

PS: Дмитрий, какие требования к участникам комитета TC-39?

Именно к TC-39 -- насколько я понимаю, подача заявки от твоей компании, ну и желательно, чтобы твоя компания была связана с разработкой JS, и была мэйнстримовой компанией по такой разработке (например, Mozilla, Google, Apple, Microsoft). Или же, ты в своей компании -- какой-нибудь идеолог-евангелист JS -- типа Крокфорда от Yahoo. Но, как мне сказал Крокфорд, нужно только, чтобы ты представлял компанию, а так -- подавай заявку.

А вот участником es-discuss листа (пассивным/активным) может быть каждый. Именно здесь ведется обсуждение дизайна ES. И ты, если есть что предложить и сказать, можешь это легко сделать. Потом уже, на митингах TC-39, это обсуждается в узком кругу. Но сами идеи, сами предложения -- могут поступать от тебя на es-discuss и вполне (если обоснованы) могут быть приняты в стандарт.