[dojo-contributors] Dojo 1.7 Goals: has() and granular dependency lists

Stephen Chung Stephen.Chung at intexact.com
Wed Mar 16 22:23:23 EDT 2011


Strange.  I was bitten by a bug that took me ages to figure out.  I was running Chrome 10 and it seems that V8’s native implementation of array prototype functions don’t iterate over sparse arrays.  Try “Array.prototype.map.call(new Array(10), function(x) { return 999; })” which still returns a sparse array.

Neither does Safari 5, nor FireFox 4.

Currently, the dojo.* array functions are mapped to native implementations only for the webkitMobile flag.  We’ve got to be careful about this because, if the user turns on webkitMobile, obviously he/she intends to build for WebKit on a mobile device, which most likely will be running Nitro or V8...

- Stephen


From: Peter Higgins 
Sent: Wednesday, 16 March, 2011 8:51 PM
To: dojo dev. 
Subject: Re: [dojo-contributors] Dojo 1.7 Goals: has() and granular dependency lists

On 3/15/11 11:18 PM, Bill Keese wrote: 
  I'd suggest just leaving array.js as is. 


  Although you could have a " config-use-native-array" flag, it'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.


  About the webkitMobile build flag, I'm not even sure that anyone is using it, so don't take those code paths too seriously.


While it is very likely few people are using it, the reality of it is that we'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'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. 

~phiggins



  2011/3/16 Kris Zyp <kzyp at dojotoolkit.org>

    Interesting. Should we do this?
    if(has("array-foreach") && has("config-use-native-array")){
      /* native array methods */

    (where config-use-native-array defaults to false)
    Thanks,
    Kris 


    On 3/15/2011 9:09 AM, Eugene Lazutkin wrote:

      If memory serves me correctly, this decision (use our implementation in
      all browsers) was done because of two factors: in almost all browsers
      native implementations were *slower* than trivial JavaScript once, and
      because of space considerations --- why ship two implemntations + a
      switch between them, if there are no other benefits?

      Just ran a test in Chrome 11 on Linux --- native versions 2-3 times
      slower on this benchmark: http://www.perfjs.com/#638003

      I tried it on FF3.6 --- forEach is twice slower, yet reduce* is almost
      the same.

      It appears that the current generation of browsers do not give us clear
      incentive to switch, other than for possible build reduction purposes.

      Cheers,

      Eugene Lazutkin
      http://lazutkin.com/

      On 03/15/2011 08:32 AM, Peter Higgins wrote:
      > All the array utilities do this in the webkit mobile build (use natives,
      > weird weird pragma at the bottom), but we were never serving native
      > iterators as our own even in browsers that support it.

      > On 3/15/11 9:13 AM, Kris Zyp wrote:
      >> On 3/14/2011 10:24 PM, Bill Keese wrote:
      >>> Doesn't your patch break backwards-compatibility?     Note the
      >>> comment in all the methods in the current code:
      >>>
      >>> //This method corresponds to the JavaScript 1.6 Array.indexOf method,
      >>> with one difference: when
      >>>
      >>> //run over sparse arrays, the Dojo function invokes the callback for
      >>> every index whereas JavaScript
      >>>
      >>> //1.6's indexOf skips the holes in the sparse array.
      >>>
      >>>
      >>
      >> I didn't write any new code, I just switched from the old build pragma
      >> to has() branching. If it is not backwards-compatible, it hasn't been
      >> backwards-compatible for sometime... So it is backwards-compatible
      >> with the old backwards-incompatibility ;).
      >>
      >> Kris
      >>
      >>
      >> _______________________________________________
      >> dojo-contributors mailing list
      >> dojo-contributors at mail.dojotoolkit.org
      >> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors



      > _______________________________________________
      > dojo-contributors mailing list
      > dojo-contributors at mail.dojotoolkit.org
      > http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

    >
    _______________________________________________

    > dojo-contributors mailing list

    > dojo-contributors at mail.dojotoolkit.org

    >
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors




    _______________________________________________
    dojo-contributors mailing list
    dojo-contributors at mail.dojotoolkit.org
    http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors




_______________________________________________
dojo-contributors mailing list
dojo-contributors at mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors




--------------------------------------------------------------------------------
_______________________________________________
dojo-contributors mailing list
dojo-contributors at mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors



--------------------------------------------------------------------------------

No virus found in this incoming message.
Checked by AVG - www.avg.com 
Version: 9.0.894 / Virus Database: 271.1.1/3509 - Release Date: 03/16/11 03:34:00
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110317/31e7b0da/attachment.htm 


More information about the dojo-contributors mailing list