Suggestions for Set

Brendan Eich 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
>     iterables?
>     >
>     > 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[0] to
>     array[length - 1] is the most expected result.
>
>
> +1
>
> 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 
iterable-else-array-like?

Holes:

http://www.youtube.com/watch?v=bFNx7YFwFfI
http://www.youtube.com/watch?v=dI-I8DQD4LI

/be


More information about the es-discuss mailing list