Uninteresting parameters
Allen Wirfs-Brock
allen at wirfs-brock.com
Thu Sep 29 10:03:13 PDT 2011
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.
Allen
> _______________________________________________
> 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/ad9eb881/attachment.html>
More information about the es-discuss
mailing list