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

Bill Keese bill at dojotoolkit.org
Thu Mar 17 02:36:04 EDT 2011


Hmm, I don't see anything at
http://bugs.dojotoolkit.org/browser/dojox/trunk/charting/DataChart.js#L99but
if our own code breaks somehow then we definitely shouldn't change the
behavior of those array functions.

I tried your test case, I see that:

>>> new Array(10).map(function(x) { return 999; })
[undefined, undefined, undefined, undefined, undefined, undefined, undefined,
undefined, undefined, undefined]

whereas:

>>> dojo.map(new Array(10), function(x) { return 999; })
[999, 999, 999, 999, 999, 999, 999, 999, 999, 999]

On Thu, Mar 17, 2011 at 12:25 PM, Stephen Chung
<Stephen.Chung at intexact.com>wrote:

>   But the dojo.* ones do iterate over sparse arrays, and at least certain
> modules depend on this fact (such as dojox.charting when creating bar
> charts) – dojox/charting/DataChart.js line 99.  This means that a user whose
> site runs perfectly would break once he makes a build with webkitMobile, and
> it will also take him ages to figure out why; may not even be possible
> unless he traces into the source code.
>
> - Stephen
>
>  *From:* Bill Keese <bill at dojotoolkit.org>
> *Sent:* Thursday, 17 March, 2011 10:42 AM
> *To:* dojo dev. <dojo-contributors at mail.dojotoolkit.org>
> *Cc:* Stephen Chung <Stephen.Chung at intexact.com>
> *Subject:* Re: [dojo-contributors] Dojo 1.7 Goals: has() and granular
> dependency lists
>
> I think that's operating according to spec, no?
>
> 2011/3/17 Stephen Chung <Stephen.Chung at intexact.com>
>
>>   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 <dante at dojotoolkit.org>
>> *Sent:* Wednesday, 16 March, 2011 8:51 PM
>> *To:* dojo dev. <dojo-contributors at mail.dojotoolkit.org>
>> *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 listdojo-contributors at mail.dojotoolkit.orghttp://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
>>
>> _______________________________________________
>> 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/3511 - Release Date: 03/17/11
> 03:34:00
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110317/590e4a26/attachment-0001.htm 


More information about the dojo-contributors mailing list