Uninteresting parameters

[Dean Landolt]

On Thu, Sep 29, 2011 at 1:03 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> On Sep 29, 2011, at 6:04 AM, Dean Landolt wrote:
>
>
>
> 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:
>>>
>>> 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 ) {
>>>
>>
> Note that 'in' sees inherited properties and that in general when talking
> about sparseness you need to be explicit about whether or not you want to
> see "holes" filled by such inherited properties.
>
> In the above algorithm you may really want to say
> builtinObjProtoHasOwnProperty.call(array,i) instead of in.
>
>  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.
>
>
> I agree, implementation can use optimized representations for sparse
> (and/or non-sparse) arrays.  If you are purposefully using sparse arrays
> then you would really like to leverage the implementations knowledge about
> sparseness.
>
> For ES next, I would think that some built-in generators that yield
> exclusively holes or non-holes  would be a good way to expose this
> knowledge.  The specification of these generators would use O(n) algorithms
> but implementations could use internal representation knowledge to make them
> more efficient.
>


I'd considered this too, but it doesn't play very nicely with Brendan's
notion of a thousand github modules blooming. You may need more control over
iteration, like controlling where to start and stop iteration.

There's an actual use case around binary data -- for instance using holes
could come in handy in node's Buffer API. IIRC there was a time they didn't
clear buffers on instantiation, a security hazard. It can be expensive to
fill a buffer with arbitrary ints -- holes would likely be a better model.
Being able to borrow ideas and API surface from the sparse array model could
be incredibly valuable for people working with things like binary data and
databases.

This is the reason I'm still pushing on the issue -- there are a whole range
of use cases hiding in sparse arrays, a lot more than head-to-tail
iteration. Exposing an API to query for holes would formalize and complete a
long-standing almost-feature of the language.

Oh, and all that said, holes in ArrayLiterals should still die a painful
death :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110929/7d2cd576/attachment.html>