Uninteresting parameters

Dean Landolt dean at deanlandolt.com
Wed Sep 28 20:05:53 PDT 2011


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). 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110928/d4d942b7/attachment.html>


More information about the es-discuss mailing list