Недавно было объявлено, что следующая версия JavaScript (ES2016) будет состоять из очень небольшого набора функций , а именно Array.prototype.include (который определяет, включено ли конкретное значение в массив или нет) и оператора возведения в степень ( который возводит число в степень показателя степени). Учитывая множество новых функций, представленных ES6, некоторые люди могут быть удивлены, насколько точно будет выпуск ES2016. Другие, с другой стороны, могут быть счастливы, что есть только две новые возможности для изучения — достижимая цель по стандартам большинства людей.
Несмотря на то, что ES2016 был таким маленьким, он вызвал несколько удивительных бровей, но также выдвинул на первый план еще одну проблему — метод Array.prototype.includesArray.prototype.containsнесовместимо с веб-интерфейсом ( прочитайте это, столкнулся бы с библиотекой MooTools, потенциально приводящей ко многим сломанным веб-сайтам).
И так оно было переименовано.
Сегодня мы спрашиваем, хорошо ли для сообщества ориентировать язык таким образом, или это «своего рода удар», что спецификация была изменена из-за библиотечного конфликта. Двое из наших авторов ( Мориц и Тим ) придерживаются противоположных точек зрения по этому вопросу.
Тим: Спец должен править, библиотеки должны подчиняться
Если вы игнорируете его причуды, JavaScript легко понять и по-настоящему гибок — он делает отличный первый язык. Это также делает отличный второй язык. Многие разработчики, которых я знаю, имели программирование истории на других языках до написания JavaScript, и, с учетом того, что Node становится все более стабильным и лучше, я думаю, что многие другие последуют его примеру.
Кажется, что мир программирования не согласен с именованием метода, чтобы проверить, существует ли элемент массива или подстрока в массиве или строке. C # и Java имеют .contains().include?()inin_array()strstr() Это вроде беспорядок. Однако в JavaScript-стране есть jQuery, Underscore, MooTools и куча других фреймворков / библиотек, которые имеют .contains() Возможно, мы можем говорить о небольшом соглашении, происходящем здесь.
Если они намереваются учитывать старые библиотеки при именовании API, я боюсь, что это только начало сверхъестественных имен
Я понимаю, что изменения могут сломать многие веб-сайты и / или приложения, но мы должны понимать, что при разнообразии существующих библиотек будут происходить критические изменения. Я ненавижу мысль, что мы готовы сделать выбор дизайна, чтобы избежать одной пули. Не то, чтобы я не соглашался с выбранным именем, но эта философия может привести к неудачному выбору дизайна в будущем, если он может сломать 1% сети из-за плохого выбора дизайна с их стороны.
Что беспокоит меня больше, так это несогласованность. Это одно изменение не превратит JavaScript в другой PHP, но TC39 должен поддерживать стандарт на высоком уровне. Например, спецификация DOM включает Node.contains () . Хотя можно утверждать, что в настоящее время реализованный .includes().includes().contains()
Я думаю, что TC39 должен сосредоточиться на поддержании аккуратности JavaScript. На других языках вы часто можете создавать и придерживаться определенной версии. Интернет, однако, не очень хорош с ограничениями или изменениями — каждый выбор постоянен. Выбирая между разрушением 1% Интернета с использованием плохо спроектированной библиотеки и сосредоточением внимания на будущем и долговечности языка, я предпочел бы выбрать последний.
Мориц: Мы не должны ломать сеть только из-за предпочтений именования
Сеть всегда была о доступности. Веб-сайт, написанный по старым стандартам (например, XHTML 1.0), по-прежнему доступен для использования сегодня и не приведет к сбоям в работе вашего браузера. JavaScript почти стал необходимостью и обеспечивает большую часть того, что мы называем Интернетом. Хорошей частью, если не большей частью, набора функций ECMAScript 2015 в прошлом году является синтаксический сахар, предназначенный для обеспечения обратной совместимости.
Акцент должен быть сделан на устранении недостатков и потребностей реального языка, а не на использовании более синтаксического сахара из других языков.
JavaScript не всегда был таким многофункциональным, как сегодня. Благодаря библиотекам и фреймворкам, таким как Prototype, jQuery, MooTools и многим другим, веб-сообщество заполнило пробелы и потребности сами. Некоторые из них стали очень популярными, другие исчезли, но все они в конечном итоге сформировали сеть и языковые спецификации.
Многие из последних дополнений JavaScript были только ответом на то, что уже предоставляют эти библиотеки. Это имеет смысл учитывать при создании новой языковой функции. Поэтому я очень рад, что Технический комитет 39 переименовал Array.prototype.includes
Как уже указывал Тим, присвоение имени функции, которая проверяет наличие элемента, является активным обсуждением в мире программирования. API-интерфейс DOM запускается с помощью схемы наименования contains()Element.classList.contains () , Node.contains () ), затем спецификация языка меняет API на include includes()Selection.containsNode () . Я также хочу, чтобы JavaScript был последовательным языком, но мы не должны начинать ломать сеть только из-за предпочтений именования. Согласованность имеет значение, но доступность сети делает больше.
Кроме того, я приветствую новый процесс выпуска спецификации ECMAScript. Отсутствие огромного набора новых функций каждый год поможет разработчикам идти в ногу с языком. Хотя, все еще должен быть приблизительный план направления ECMAScript. Добавление новых функций только для того, чтобы отвечать потребностям текущей тенденции , закончится раздутым языком. Акцент должен быть сделан на устранении недостатков и потребностей реального языка, а не на использовании более синтаксического сахара из других языков.
К вам
Так что у вас есть это. Должны ли мы твердо стоять в центре и сосредоточиться на будущем и долговечности языка, который мы любим, или нам следует избегать взлома сети из-за предпочтений именования?
Нельзя отрицать, что называть вещи сложно. Как говорится , в компьютерной науке есть две непростые вещи: аннулирование кэша, присвоение имен и ошибки «один на один».
На какую сторону дискуссии вы попадаете? Мы хотели бы услышать от вас в комментариях.