Uninteresting parameters

[Rick Waldron]

On Wed, Sep 28, 2011 at 11:05 PM, Dean Landolt <dean at deanlandolt.com> wrote:

>
>
> On Wed, Sep 28, 2011 at 10:06 PM, Mike Shaver <mike.shaver at gmail.com>wrote:
>
>> On Wed, Sep 28, 2011 at 9:11 PM, Brendan Eich <brendan at mozilla.com>
>> 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] );
}
}




> Regardless of where it goes (on Array, Array.prototype, or in a system
> module), all we really need is something like a function that takes an index
> and direction and returns the next hole's start index and length (or end
> index). I'll put together a proposal if this isn't too controversial.
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110929/28a3fb08/attachment.html>