iterate and enumerate trap signature inconsistency

[Mark S. Miller]

On Tue, Sep 11, 2012 at 12:50 PM, David Bruant <bruant.d at gmail.com> wrote:

> I don't remember what the rational of the duplicate check was. Do we
> really need it?
> A lot of invariants are here for the sake of robustness/security
> (especially non-configurable/non-writable/non-extensible-related
> invariants), but it doesn't seem duplicate keys will make code less
> robust or secure.
>
> Unless there are strong reasons to preserve this invariant, it could be
> dropped, couldn't it?


It is a tradeoff. Without relying on some guarantees, it is impossible to
write correctly defensive code. With every guarantee that is 1) enforced by
ES5/strict, 2) typically obeyed in ES6, and 3) convenient to rely on, there
likely will be ES5-era code whose correctness relies on these guarantees.
When new versions of the language un-enforce a previously enforced
guarantee, old correctly defensive code can fail to defend against attacks
possible only on the new platform.

OTOH, in the extreme, to not weaken any guarantees is to prevent the
language from evolving to provide more power. Both Proxies and
Object.observe were carefully designed to strike a good balance between
these pressures. For the old enumerate trap design, the cost vs benefit of
preserving the no-duplicate guarantee seemed worth it. If we change this
API from returning an array of strings to returning an iterator, I agree
that alters the balance and justifies waiving this particular guarantee.

-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120911/40f23f04/attachment.html>