<font size="2">Yes, it seems unlikely that anyone is calling dojo.forEach(ary, callback) with a sparse array, let alone depending on the callback() being called for holes in the array.   The pros/cons of branching to native functions when native methods are available are:</font><div>
<br></div><div><font size="2"></font>Pro:</div><div>- size reduction of mobile-specific builds</div><div><br></div><div>Con:</div><div>- runs slower</div><div>- size increase for non-browser specific builds</div><div>- minor API change</div>
<div><br><div><font size="2"><br></font></div><div><font size="2">Anyway, I don&#39;t really care one way or the other, was just pointing out the back-compat break.</font></div><div><font size="2"><br></font><br><div class="gmail_quote">
2011/3/16 Peter Higgins <span dir="ltr">&lt;<a href="mailto:dante@dojotoolkit.org">dante@dojotoolkit.org</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


  
    
  
  <div text="#000000" bgcolor="#ffffff"><div class="im">
    On 3/15/11 11:18 PM, Bill Keese wrote:
    <blockquote type="cite"><font size="2">I&#39;d suggest just leaving array.js as
        is.</font>
      <div><font size="2"><br>
        </font></div>
      <div><font size="2">Although you could have a &quot;
          
          config-use-native-array&quot; flag, it&#39;s probably not worth the
          confusion for users, especially since you need to explain how
          dojo.forEach() etc. would behave differently depending on the
          browser.</font></div>
      <div><font size="2"><br>
        </font></div>
      <div><font size="2">About the webkitMobile build flag, I&#39;m not
          even sure that anyone is using it, so don&#39;t take those code
          paths too seriously.<br>
        </font><br>
      </div>
    </blockquote></div>
    While it is very likely few people are using it, the reality of it
    is that we&#39;ve sent natives there for [however long] and no one seems
    have been bitten by the fact they are able to walk over sparse
    arrays. All the major libraries (afaik) don&#39;t do sparse arrays
    unless deferring to native, and it seems like either a) no one [as
    in more than just the no ones that use webkitmobile] uses sparse
    arrays in real life or b) see a. <br>
    <br>
    ~phiggins<div><div></div><div class="h5"><br>
    <br>
    <br>
    <blockquote type="cite">
      <div>
        <div class="gmail_quote">
          2011/3/16 Kris Zyp <span dir="ltr">&lt;<a href="mailto:kzyp@dojotoolkit.org" target="_blank">kzyp@dojotoolkit.org</a>&gt;</span><br>
          <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
            <div bgcolor="#FFFFFF" text="#000000"> Interesting. Should
              we do this?<br>
              if(has(&quot;array-foreach&quot;) &amp;&amp;
              has(&quot;config-use-native-array&quot;)){<br>
                /* native array methods */<br>
              <br>
              (where config-use-native-array defaults to false)<br>
              Thanks,<br>
              <font color="#888888"> Kris</font>
              <div>
                <div><br>
                  <br>
                  On 3/15/2011 9:09 AM, Eugene Lazutkin wrote:<br>
                  <blockquote type="cite">If memory serves me correctly,
                    this decision (use our implementation in<br>
                    all browsers) was done because of two factors: in
                    almost all browsers<br>
                    native implementations were *slower* than trivial
                    JavaScript once, and<br>
                    because of space considerations --- why ship two
                    implemntations + a<br>
                    switch between them, if there are no other benefits?<br>
                    <br>
                    Just ran a test in Chrome 11 on Linux --- native
                    versions 2-3 times<br>
                    slower on this benchmark: <a href="http://www.perfjs.com/#638003" target="_blank">http://www.perfjs.com/#638003</a><br>
                    <br>
                    I tried it on FF3.6 --- forEach is twice slower, yet
                    reduce* is almost<br>
                    the same.<br>
                    <br>
                    It appears that the current generation of browsers
                    do not give us clear<br>
                    incentive to switch, other than for possible build
                    reduction purposes.<br>
                    <br>
                    Cheers,<br>
                    <br>
                    Eugene Lazutkin<br>
                    <a href="http://lazutkin.com/" target="_blank">http://lazutkin.com/</a><br>
                    <br>
                    On 03/15/2011 08:32 AM, Peter Higgins wrote:<br>
                    &gt; All the array utilities do this in the webkit
                    mobile build (use natives,<br>
                    &gt; weird weird pragma at the bottom), but we were
                    never serving native<br>
                    &gt; iterators as our own even in browsers that
                    support it.<br>
                    <br>
                    &gt; On 3/15/11 9:13 AM, Kris Zyp wrote:<br>
                    &gt;&gt; On 3/14/2011 10:24 PM, Bill Keese wrote:<br>
                    &gt;&gt;&gt; Doesn&#39;t your patch break
                    backwards-compatibility?     Note the<br>
                    &gt;&gt;&gt; comment in all the methods in the
                    current code:<br>
                    &gt;&gt;&gt;<br>
                    &gt;&gt;&gt; //This method corresponds to the
                    JavaScript 1.6 Array.indexOf method,<br>
                    &gt;&gt;&gt; with one difference: when<br>
                    &gt;&gt;&gt;<br>
                    &gt;&gt;&gt; //run over sparse arrays, the Dojo
                    function invokes the callback for<br>
                    &gt;&gt;&gt; every index whereas JavaScript<br>
                    &gt;&gt;&gt;<br>
                    &gt;&gt;&gt; //1.6&#39;s indexOf skips the holes in the
                    sparse array.<br>
                    &gt;&gt;&gt;<br>
                    &gt;&gt;&gt;<br>
                    &gt;&gt;<br>
                    &gt;&gt; I didn&#39;t write any new code, I just
                    switched from the old build pragma<br>
                    &gt;&gt; to has() branching. If it is not
                    backwards-compatible, it hasn&#39;t been<br>
                    &gt;&gt; backwards-compatible for sometime... So it
                    is backwards-compatible<br>
                    &gt;&gt; with the old backwards-incompatibility ;).<br>
                    &gt;&gt;<br>
                    &gt;&gt; Kris<br>
                    &gt;&gt;<br>
                    &gt;&gt;<br>
                    &gt;&gt;
                    _______________________________________________<br>
                    &gt;&gt; dojo-contributors mailing list<br>
                    &gt;&gt; <a href="mailto:dojo-contributors@mail.dojotoolkit.org" target="_blank">dojo-contributors@mail.dojotoolkit.org</a><br>
                    &gt;&gt; <a href="http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors" target="_blank">http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors</a><br>
                    <br>
                    <br>
                    <br>
                    &gt; _______________________________________________<br>
                    &gt; dojo-contributors mailing list<br>
                    &gt; <a href="mailto:dojo-contributors@mail.dojotoolkit.org" target="_blank">dojo-contributors@mail.dojotoolkit.org</a><br>
                    &gt; <a href="http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors" target="_blank">http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors</a><br>
                  </blockquote>
                  <span style="white-space:pre-wrap">&gt;<br>
                    _______________________________________________<br>
                    <br>
                    &gt; dojo-contributors mailing list<br>
                    <br>
                    &gt; <a href="mailto:dojo-contributors@mail.dojotoolkit.org" target="_blank">dojo-contributors@mail.dojotoolkit.org</a><br>
                    <br>
                    &gt;<br>
                    <a href="http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors" target="_blank">http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors</a></span><br>
                  <br>
                  <br>
                </div>
              </div>
            </div>
            <br>
            _______________________________________________<br>
            dojo-contributors mailing list<br>
            <a href="mailto:dojo-contributors@mail.dojotoolkit.org" target="_blank">dojo-contributors@mail.dojotoolkit.org</a><br>
            <a href="http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors" target="_blank">http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors</a><br>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
      <pre><fieldset></fieldset>
_______________________________________________
dojo-contributors mailing list
<a href="mailto:dojo-contributors@mail.dojotoolkit.org" target="_blank">dojo-contributors@mail.dojotoolkit.org</a>
<a href="http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors" target="_blank">http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors</a>
</pre>
    </blockquote>
    <br>
  </div></div></div>

<br>_______________________________________________<br>
dojo-contributors mailing list<br>
<a href="mailto:dojo-contributors@mail.dojotoolkit.org">dojo-contributors@mail.dojotoolkit.org</a><br>
<a href="http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors" target="_blank">http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors</a><br>
<br></blockquote></div><br></div></div>