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

Kris Zyp kzyp at dojotoolkit.org
Thu Mar 17 12:18:21 EDT 2011


Even if we don't make any changes to array.js, question of using the
has() pattern for config information is still pertinent. It seems like
it would be very beneficial for builds to be able to resolve config
branches to eliminate unneeded code when config information can be
provided to the build without any additional parsing overhead. Another
example of config information driving branching would be in the events
handling module where you can configure whether or not to use the IE
memory leak adjustment code (I say adjustment, because from what I
understand, fixing between page memory leaks actually can induce in-page
memory leaks). If a user wants configure to the app to omit the memory
leak adjustment, then it would be nice if that configuration led to the
omission of the unneeded code. So is this reasonable:

if(!has("config-allow-leaks")){/* memory leak code */}

Thanks,
Kris


On 3/16/2011 6:51 AM, Peter Higgins wrote:
> 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 <mailto: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
>>>     <mailto:dojo-contributors at mail.dojotoolkit.org>
>>>     >> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>>>
>>>
>>>
>>>     > _______________________________________________
>>>     > dojo-contributors mailing list
>>>     > dojo-contributors at mail.dojotoolkit.org
>>>     <mailto:dojo-contributors at mail.dojotoolkit.org>
>>>     > http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>>     >
>>     _______________________________________________
>>
>>     > dojo-contributors mailing list
>>
>>     > dojo-contributors at mail.dojotoolkit.org
>>     <mailto:dojo-contributors at mail.dojotoolkit.org>
>>
>>     >
>>     http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>>
>>
>>
>>     _______________________________________________
>>     dojo-contributors mailing list
>>     dojo-contributors at mail.dojotoolkit.org
>>     <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110317/2c00272a/attachment.htm 


More information about the dojo-contributors mailing list