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).
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
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.
> complicated library to use it? And even with such a library, it's
> still much more complicated to use than a simple "delay" keyword.
> "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
For instance, private names cannot be implemented today and they answer
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
There is also a trick with calling postMessage to send yourself a
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss