[Dojo-interest] Becoming promises-aplus compliant
shane.green at me.com
Mon Apr 22 08:23:05 EDT 2013
Why should performance matter?
805-452-9666 | shane.green at me.com
On Apr 22, 2013, at 5:04 AM, Dan Rumney <dancrumb at gmail.com> wrote:
> I have to admit, I was also a little confused about the discussion around the performance of callbacks when a Deferred is already resolved. Why should this ever matter?
> Like Eugene, I write my asynchronous code with the assumption that any Deferred callbacks could be called at any time. Writing async code in our applications using assumptions about whether it will (or will not) run in the current execution thread would be considered a major design flaw.
> Sent from my iPhone
> On Apr 22, 2013, at 1:04, Eugene Lazutkin <eugene.lazutkin at gmail.com> wrote:
>> I am all for the code correctness. Yet implementing promises three times
>> now, I don't understand the problem. Could you explain what is it
>> exactly? Better yet, do you have a code I can use to test the problem
>> you experienced?
>> My rule of thumb for promise callbacks is simple: do not make any
>> assumptions about when this code is going to run. So far it worked with
>> my implementations, and with others. Did I miss something?
>> On 04/21/2013 08:42 PM, James Burke wrote:
>>> On Sun, Apr 21, 2013 at 2:05 PM, Eugene Lazutkin
>>> <eugene.lazutkin at gmail.com> wrote:
>>>> Still I don't see why "the next turn" should be a universal answer for
>>>> all use cases, even if we forget about its implementation for a moment.
>>>> here are places, when it is appropriate, that's true, but it is far from
>>>> a universal requirement. Moreover, if I want a delay, I can add it, with
>>>> the current implementation, when needed. The latter is not true for
>>>> delay-based promises --- you cannot make them immediate no matter what
>>>> you do.
>>> I am not doing the work, just a bystander, so feel free to discard:
>>> In the interests of compat, the default be next turn. I've written AMD
>>> loaders that try doing sync or next turn on the fly, and it is
>>> difficult to get the logic right. In short, I have hit code
>>> correctness bugs that are hard to get right if there is a mixture. And
>>> this is all in code I control.
>>> Code correctness and allowing dojo modules to be composable with other
>>> modules and that may use other promise implementations are more
>>> important than speed concerns. Using the postMessage hack and
>>> setImmediate where available should be used if measured to be faster
>>> than alternatives, and try to push for faster next turn capabilities
>>> in JS environments when available options are not sufficient. As DOM
>>> Futures get further along, there will be natural pressure to get fast
>>> next turn anyway.
>>> Dojo Toolkit: http://dojotoolkit.org/
>>> Tutorials: http://dojotoolkit.org/documentation/
>>> Reference Guide: http://dojotoolkit.org/reference-guide
>>> API Documentation: http://dojotoolkit.org/api
>>> Dojo-interest at mail.dojotoolkit.org
>>> To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
>> Eugene Lazutkin
>> Dojo Toolkit: http://dojotoolkit.org/
>> Tutorials: http://dojotoolkit.org/documentation/
>> Reference Guide: http://dojotoolkit.org/reference-guide
>> API Documentation: http://dojotoolkit.org/api
>> Dojo-interest at mail.dojotoolkit.org
>> To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
> Dojo Toolkit: http://dojotoolkit.org/
> Tutorials: http://dojotoolkit.org/documentation/
> Reference Guide: http://dojotoolkit.org/reference-guide
> API Documentation: http://dojotoolkit.org/api
> Dojo-interest at mail.dojotoolkit.org
> To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dojo-interest