Uninteresting parameters

[Dean Landolt]

On Thu, Sep 29, 2011 at 12:13 AM, Rick Waldron <waldron.rick at gmail.com>wrote:

>
>
> On Thu, Sep 29, 2011 at 12:09 AM, Rick Waldron <waldron.rick at gmail.com>wrote:
>
>>
>>
>> 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] );
>> }
>> }
>>
>>
>>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110929/19c4343f/attachment.html>