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

Bill Keese bill at dojotoolkit.org
Wed Mar 16 22:20:03 EDT 2011


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:

Pro:
- size reduction of mobile-specific builds

Con:
- runs slower
- size increase for non-browser specific builds
- minor API change


Anyway, I don't really care one way or the other, was just pointing out the
back-compat break.


2011/3/16 Peter Higgins <dante at dojotoolkit.org>

>  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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110317/9b51e32f/attachment.htm 


More information about the dojo-contributors mailing list