Suggestions for Set
brendan at mozilla.com
Wed Oct 3 08:05:38 PDT 2012
Rick Waldron wrote:
> On Wed, Oct 3, 2012 at 10:47 AM, Erik Arvidsson
> <erik.arvidsson at gmail.com <mailto:erik.arvidsson at gmail.com>> wrote:
> On Wed, Oct 3, 2012 at 3:24 AM, Andreas Rossberg
> <rossberg at google.com <mailto:rossberg at google.com>> wrote:
> > On 3 October 2012 05:38, Brendan Eich <brendan at mozilla.com
> <mailto:brendan at mozilla.com>> wrote:
> >> Which is more important, iterating over holes (preserved if
> possible), or
> >> skipping them and therefore spreading array-likes but not
> > I, for one, couldn't care less about holes. We shouldn't compromise
> > any useful feature just for the sake of preserving some array hole
> > craziness.
> Filling in holes with undefined seems like the right thing to do.
> People do not depend on holes.
> Having Array.prototype. at iterator skip holes is bad because we don't
> have the index so we don't know that anything was skipped.
> To repeat myself; holes are not common and we should keep things
> simple and having Array.prototype. at iterator iterate over array to
> array[length - 1] is the most expected result.
> In the "trenches", most devs consider holes to be a myth. Most have
> never seen or had experience with code that relies on holes or even
> suffers when holes exist. There are many sources that will back this
> claim, but at the moment I can't invest the time to look up and
> compile a list (if i have time later)
Ok, I buy it.
In that case, why shouldn't spread match Array.from and use
More information about the es-discuss