Le 19 août 2014 à 06:47, Kevin Smith zenpars...@gmail.com a écrit :
Background:
http://esdiscuss.org/topic/next-yo-in-newborn-generators
http://esdiscuss.org/topic/april-8-2014-meeting-notes
It appears that the current state of affairs is that the argument supplied to
the first call of
// the same, advancing to the first `yield` at instantiation
class echo2 extends echo {
construct(...args) {
let iter = super(...args)
iter.next()
return iter
}
}
Nice pattern! Would this also work?
var skipFirst = genFn = function*(...args) {
Originally this came up while studying these slides on async generators:
https://docs.google.com/file/d/0B4PVbLpUIdzoMDR5dWstRllXblU/edit
In this design, `Observable.observe` is specified as taking a generator
which acts as a data sink. However, because of the lost next issue, it
appears that
(For some reason, e-mails containing the following text have failed to
make it to the es-discuss list. Not sure what's going on with that.
Anyway, this is a new e-mail that contains more or less the same contents
but changed a bit in case there's some filter or bug that the last e-mails
were
Le 19 août 2014 à 15:21, Kevin Smith zenpars...@gmail.com a écrit :
// the same, advancing to the first `yield` at instantiation
class echo2 extends echo {
construct(...args) {
let iter = super(...args)
iter.next()
return iter
}
}
Nice pattern! Would
I think that only makes sense if 'this.import()' worked for
script-tags-marked-as-modules in general. If the general case supported it,
then it should just work for HTML imports.
OTOH, I think System.import() is clearer.
jjb
On Mon, Aug 18, 2014 at 6:23 PM, Matthew Robb matthewwr...@gmail.com
On Mon, 18 Aug 2014, John Barton wrote:
Your examples use script. I just don't think now that we should use the
same solution for HTML. We should analyze the HTML requirements and design
a solution. If the result is similar to script then we can reuse.
That's what I've been doing. My
Assuming we use the ES6 module loader to handle all the loads in an HTML
document, in the Web context, there are some interesting questions to
resolve around the issue of de-duping.
Suppose you had this markup snippet:
style
@import http://example.com/foo.x;;
/style
script
It would be helpful if there was a way that the module _execution_ (after
it's been parsed and dependencies have been extracted) could be delayed
by the loader.
Suppose a page is loading and has reached a quiescent state, and so the
browser thinks ok, time to preload some scripts. It might
Google Postini quarantined three of your messages. I moderated them
through and sender-whitelisted your email address.
Anyone (including me) in a similar boat, please mail me and I'll fix
ASAP. I don't know who else can moderate. I just renewed admin access
the other week when my own posts
Sadly, it doesn't work; for the delegated iterator always receives
`undefined` for its first iteration. :-(
See [1], last algorithm of the section, step 5.
Ah, thanks.
In your class-based solution, is construct supposed to be constructor?
___
The loader is designed to enable deferred execution, but there isn't an
easy hook to allow this that I know of.
System.define is the only load function that does not ensure execution. The
others (System.import, System.load, System.module), run an EnsureEvaluated
call to run the scripts.
It could
Le 19 août 2014 à 20:34, Kevin Smith zenpars...@gmail.com a écrit :
In your class-based solution, is construct supposed to be constructor?
Yes, sure. I was negatively influenced by some language where the constructor
is named __construct.
—Claude
inline...
On Aug 19, 2014, at 12:52 PM, Ian Hickson i...@hixie.ch wrote:
(For some reason, e-mails containing the following text have failed to
make it to the es-discuss list. Not sure what's going on with that.
Anyway, this is a new e-mail that contains more or less the same contents
On Mon, 18 Aug 2014, John Barton wrote:
On Mon, Aug 18, 2014 at 10:55 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 13 Aug 2014, Ian Hickson wrote:
One of the problems I'm running into when it comes to trying to
integrate ES6 modules with HTML and new HTML-based dependency
features
On Mon, 18 Aug 2014, John Barton wrote:
On Mon, Aug 18, 2014 at 2:06 PM, Ian Hickson i...@hixie.ch wrote:
Now, in the main page, you reference the HTML import:
link rel=import href=foo.html
Now how would you refer to the modules? We can't have #b refer
On Mon, 18 Aug 2014, John Barton wrote:
(For example, a graphical game might need some sprite assets to be
loaded before it can start up. So its script might be marked as
depending on an img element that loads that image. Or the script
contents might have an import statement that
On Tue, 19 Aug 2014, caridy wrote:
IMO, it is a bad idea to use the loader for preloading things.
The problem is that you need to, otherwise if someone suddenly invokes the
things in question you won't be able to relate the preloading that is
already on the fly with the actual loading that
On Tue, 19 Aug 2014, Guy Bedford wrote:
The loader is designed to enable deferred execution, but there isn't an
easy hook to allow this that I know of.
System.define is the only load function that does not ensure execution.
The others (System.import, System.load, System.module), run an
I've been spending time lately writing a lot of repeated validation code
for function parameters and using popular object schema validation
libraries like Joi (https://github.com/hapijs/joi) which led me to
re-reading and thinking about strawman:guards (
See also
http://disnetdev.com/blog/2011/08/23/Contracts.coffee-Contracts-For-JavaScript-and-CoffeeScript/
and http://research.microsoft.com/apps/pubs/default.aspx?id=224900
I am a fan of making it notationally easier to inject runtime validation of
some sort, whether starting from guards or from
+1 for https://research.microsoft.com/pubs/224900/safets.pdf ... some
really good research. As Mark said, though, it's more likely we'll get a
fight than anything productive from such a conversation, which is quite
unfortunate :( .
- Jonathan
On Tue, Aug 19, 2014 at 10:52 PM, Mark S. Miller
22 matches
Mail list logo
