Point 1 wasn't for your answer, I should have specified that, while the code was a playground for the magic setter in case MooTools guys would like to test a solution for contains or other methods too. Can't see how that could be smaller but it doesn't matter, it's small enough already.
Regards -----Original Message----- From: "Brendan Eich" <[email protected]> Sent: 01/10/2014 09:23 To: "Andrea Giammarchi" <[email protected]> Cc: "Mark S. Miller" <[email protected]>; "[email protected]" <[email protected]> Subject: Re: Array.prototype.contains solutions Andrea Giammarchi wrote: > 1. I wasn't advocating to break the web but to **not** change the > name because of a library bug, the initial thread spoiler was not needed I wasn't responding to you, here on this thread (where you hadn't posted till now) or on the other one, so why are you jumping in and talking about what you were not advocating? > 2. the `@@enumerableWhenAssigned` might lead to shenanigans but it's > *polyfillable* which is IMO preferable if it can solve somehow the problem No need to write lots of code. The problem I see with these implicit/modal hacks is that they can easily break other code that doesn't want an override of a non-enumerable to be enumerable. The magic proto-setter (Domenic's option 2) is "polyfillable", as Mark noted: no new kernel-language semantics required. It's also simpler than what you wrote, and doesn't risk blowback by breaking other code expecting non-enumerability to be preserved. /be
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
