"delay" keyword

David Bruant bruant.d at gmail.com
Thu Jul 5 03:04:08 PDT 2012


Le 05/07/2012 11:08, Patrik Stutz a écrit :
> I've read the articles you linked to and still think that 'delay' 
> would be a great idea! I think this 
> <http://calculist.org/blog/2011/12/14/why-coroutines-wont-work-on-the-web/> post 
> is wrong in many things. In my opinion, "coroutines" would be even 
> simpler to implement (depending on the current design of the engine).
I am not a JavaScript engine implementors (Dave Herman is, by the way), 
but from what I know, coroutines would require to store stack frames to 
enable running them later. If it's not something done already, it may be 
complicated to do. JavaScript engines are engineered for performance of 
today's JavaScript and today, there is no coroutine (this probably 
stands for generators, but some engines already have generators)

> Also, using generators is complicated as hell and in the end still 
> does nothing useful since "yield" is not asynchronus at all. All the 
> libraries that use generators do a lot to make you feel like it were 
> asynchronous behind the scenes, but it isnt.
>
> Do you really want to add a feature to JavaScript, for that you need a 
> complicated library to use it? And even with such a library, it's 
> still much more complicated to use than a simple "delay" keyword.
>
> While generators & libraries for it would overcomplicate JavaScript, 
> "delay" would be dead simple to use. It would fit much better into the 
> language since the rest of the language is also designed very simple.
Your post contains a lot of opinions, feelings and things that you think 
and adding new features is not really about what a particular person 
thinks in my opinion.
For any features to be added to the language, nothing is really about 
opinion. It all start with use cases.
Could you show something that 'delay' enables that is not possible 
currently?
For instance, private names cannot be implemented today and they answer 
to a need of JavaScript developers who want better encapsulation idioms.

If there is no such thing, is it a major improvement by comparison to 
what is possible today?
For instance, WeakMaps, Maps and Sets can actually be implemented today, 
but with bad performances or relying on mechanisms with unreliable 
performance, so having them implemented in the language offers some 
guarantees of performance.


I am not asking for yes/no answers, but actual code snippets taken out 
of real projects showing how 'delay' would make the code easier to read 
or understand, to reason about.


One point made by Dave in his article is very compelling:
"Once you add coroutines, you never know when someone might call 
|yield|. Any function you call has the right to pause and resume you 
whenever they want".
=> This makes very difficult to build programs using libraries.

"Generators are a lot like coroutines, with one important difference: 
they only suspend their own function activation."
=> And suddenly, your code is not affected by another function being a 
generator. When you call a function, it either never return (infinite 
loop), returns or throws an exception (which is just a different form of 
return for that matter).

>
> all you'd have change in the example is use something else than 
> setTimeout, and make the delay a function call instead..
>
> Cool! But what are the alternatives to "setTimeout" on the browser 
> side wich dont have any delay?
setTimeout(f ,0) could work, but has a small delay for historical reasons.
Microsoft is coming up with setImmediate (I haven't heard anyone 
following) 
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/setImmediate/Overview.html
There is also a trick with calling postMessage to send yourself a 
message: http://dbaron.org/log/20100309-faster-timeouts

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120705/644ab689/attachment-0001.html>


More information about the es-discuss mailing list