javascript - What's the purpose of allowing duplicate property names? -

i'm reading mdn javascript reference, accordingly following code no longer returns 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;   } } 

in ecmascript 5 strict mode code, duplicate property names considered syntaxerror. introduction of computed property names making duplication possible @ runtime, ecmascript 6 has removed restriction.

my question is, practical benefits of allowing duplicate property-names in initializers? can see, how when object properties assigned dynamically might occur, since order of precedence apparently determines of properties set on newly created object -- seems more indefinite behaviour that's best avoided.

what practical benefits of allowing duplicate property-names in initializers

there no practical benefits such. there computed property keys in ecma script 6, actual value of keys determined @ runtime. is, keys can added objects @ runtime , overwrite existing key , value. same behavior extended in es-6 , restriction of not allowing compile time duplicate keys check removed.

quoting allen wirfs-brock discussion in esdiscuss mailing list,

the plan has been runtime validation performed object literals containing computed property keys , current spec. draft contains pseudo code doing checks. bug report (https://bugs.ecmascript.org/show_bug.cgi?id=1863 ) points out issue current spec. example, current spec. throws error on:

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

but not on:

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

basically, it isn't sufficient check defined property key when processing property definitions contains computed key. if computed keys exist checking has done definitions have literal property names. , isn't sufficient consider property keys , data/accessor property distinction, validation has take account syntactic form of definition , whether or not strict mode applies..

it turns out in pseudo code, complicated set of runtime validation rules apply. i'm having hard time convincing myself runtime computational , meta data costs of dynamic validation justified. costs , actual benefit pretty small.

for reason, propose drop runtime validation of object literals (and class definition). still have static validation , errors property definitions don't have computed keys. makes past checks (including property definitions computed names) processed sequentially no duplicate name checking.

so, proposal retain compile time check normal keys , as per comment check dropped later. in revision 26,

eliminated duplicate property name restrictions on object literals , class definitions