Какова цель предоставления дубликатов имен свойств?

Я читаю ссылку MDN javascript, соответственно следующий код больше не возвращает false:

function haveES6DuplicatePropertySemantics(){
  "use strict";
  try {
    ({ prop: 1, prop: 2 });

    // No error thrown, duplicate property names allowed in strict mode
    return true;
  } catch (e) {
    // Error thrown, duplicates prohibited in strict mode
    return false;
  }
}

В коде строгого режима ECMAScript 5 дублирующиеся имена свойств были считается синтаксисом. С введением вычислимого имущества имена, делающие дублирование возможными во время выполнения, ECMAScript 6 удалил это ограничение.

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

Ответы

Ответ 1

каковы практические преимущества предоставления дубликатов имен свойств в инициализаторах

Практически не существует практических преимуществ. Теперь, когда в ECMA Script 6 есть вычислимые ключи свойств, фактическое значение ключей будет определено только во время выполнения. Как бы то ни было, ключи могут быть добавлены к объектам во время выполнения, и они перезаписывают существующий ключ и значение. Такое же поведение расширено в ES-6, и ограничение на то, чтобы не разрешать проверку дубликатов ключей компиляции, удаляется.

Цитата Allen Wirfs-Brock из обсуждения в списке рассылки ESDiscuss,

Предполагалось, что проверка выполнения будет выполняться для любых литералов объектов, содержащих вычисленные ключи свойств и текущую спецификацию. черновик содержит псевдокод для выполнения проверок. Однако отчет об ошибке (https://bugs.ecmascript.org/show_bug.cgi?id=1863) указывает на проблему с текущей спецификацией. Например, текущая спецификация. выдает сообщение об ошибке:

({get a() {},
   get ["a"]() {}
 });

но не включен:

({get ["a"]() {},
   get a() {}
 });

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

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

По этой причине я предлагаю отказаться от проверки выполнения объектных литералов (и определения класса). Мы по-прежнему будем иметь статическую проверку и ранние ошибки для определения свойств, у которых нет вычисленных ключей. Но все, что пропускает эти проверки (включая все определения свойств с вычисленными именами), обрабатывается последовательно без повторной проверки имени.

Итак, предложение состояло в том, чтобы сохранить проверку времени компиляции для обычных ключей и в соответствии с этим комментарием, проверка была удалена позже. В Редакция 26,

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