Explain the rationale behind loss of duplicate-key exception

[tdd]

Hi Nicholas,

Location: Chapter 4 > Page 75 > "Duplicate Object Literal Properties" > Par between code blocks

So you warn us that ES6 has removed duplicate-key checks. As this seems counter-productive ("why remove a useful check?"), it might be useful to detail the rationale behind this decision.

I would assume this is to maintain consistency with Object.assign and upcoming stage-3 rest/spread properties, but perhaps it's due to something else?

Still, I find this reversal dangerous, as it often caught misplaced code pastes that accidentally overwrote, or were overwritten by, another prop/method definition earlier/later in the object, for instance. But hey, done deal.

[nzakas]

As I understand it, this check was removed because there is no way to know when a computed object literal property will resolve to an already-existing statically-defined property. It was an all-or-nothing thing: either you can guarantee the check 100% of the time or you can't, and it turned out, you can't.

It's a bit late for me to add a good description of why this happened into the book (as it would require examples), so we'll just have to leave this as-is.