On Thu, Sep 29, 2011 at 12:13 AM, Rick Waldron <[email protected]>wrote:
> > > On Thu, Sep 29, 2011 at 12:09 AM, Rick Waldron <[email protected]>wrote: > >> >> >> On Wed, Sep 28, 2011 at 11:05 PM, Dean Landolt <[email protected]>wrote: >> >>> >>> >>> On Wed, Sep 28, 2011 at 10:06 PM, Mike Shaver <[email protected]>wrote: >>> >>>> On Wed, Sep 28, 2011 at 9:11 PM, Brendan Eich <[email protected]> >>>> wrote: >>>> > No worries, array extras are a great addition, we just need to keep >>>> rolling. >>>> >>>> Oh, no offense taken. I just meant to say that there may be >>>> consistency-with-existing-pattern reasons to prefer one hole behaviour >>>> over another, is all. >>>> >>> >>> >>> Another reason to prefer the current hole-hopping behavior for array >>> extras is that it's currently the *only* way to get any efficiency >>> advantage sparse arrays. So regardless of rationale, it's strictly more >>> featureful and almost certainly the intended behavior if, as a developer, >>> you're aware of holes. >>> >>> But to reiterate the point I made earlier, in order for libraries to take >>> complete ownership of looping constructs we need a better way to detect >>> holes in userland -- something that can be optimized. I was trying to think >>> of a way to overload Array.prototype.indexOf and lastIndexOf but since we >>> don't have a type for holes this isn't really feasible (I'd thought of using >>> NaN as a sigil here as it's otherwise untestable in indexOf, but this would >>> be wrong on so many levels). >>> >> >> Holes can be detected and skipped by using the "in" operator... >> >> var array = [ 1, , 3, , 5 ]; >> >> for ( var i = 0; i < array.length; i++ ) { >> // Skip accessing in sparse arrays >> if ( i in array ) { >> console.log( array[i] ); >> } >> } >> >> >> > Sorry, that is to say you could do the reverse to detect and access their > index positions > I'm aware -- that's why I said we need a *better* way. This O(N) op is incredibly wasteful on a arrays -- in fact, it completely defeats the purpose. As it stands, the only way to efficiently iterating sparse arrays is with array-extras, and if efficient iteration of sparse arrays is the only reason to have holes in the first place, this is a bit of a fail. The cleanest way I can think of to open the doors to userland optimizations is exposing a method to find hole indexes.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
