Le 27/01/2014 06:45, Brendan Eich a écrit :
Kevin Smith wrote:
Is a new attribute necessary? What about using @type?
Old browsers will ignore unknown types, losing the two-way
fallback option.
Two-way fallback? Why is that important? Since modules are
implicitly strict,
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/eval?redirectlocale=en-USredirectslug=JavaScript%2FReference%2FGlobal_Objects%2FObject%2Feval
What browsers supported it?
___
es-discuss mailing list
On Mon, Jan 27, 2014 at 12:07 PM, John Lenz concavel...@gmail.com wrote:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/eval?redirectlocale=en-USredirectslug=JavaScript%2FReference%2FGlobal_Objects%2FObject%2Feval
What browsers supported it?
In this
Once you focus on inline bodies, you face harsh adoption barriers without
enabling works-in-old-and-new coding.
OK, I follow.
However, I'm sympathetic with David because adding an attribute
specifically to fix the JS script/module issue is
design-entropy-increasing.
I wonder to what
historically window.eval(str, ctx) accepted a second argument too able to
give you access inside the context scope, similar to the one you have
through the prototype.
Firefox 2.X and FF 3, if I remember correctly, should expose those
features, as well as some Rhino 1.6 or lower
Regards
On Mon,
Thanks for the explanation.
Given all of the costs, perhaps it is worth reconsidering the benefit.
Many issues affect the load timing of web pages, will this one change make
such an improvement that it's worth the disruption it causes?
On Sat, Jan 25, 2014 at 3:31 PM, Brendan Eich
Le 27/01/2014 19:41, David Herman a écrit :
On Jan 27, 2014, at 2:07 AM, David Bruant bruan...@gmail.com wrote:
Indeed. I'm wondering why we need inline script for modules.
Because people write inline scripts all the time. It's unacceptably
inconvenient not to be able to bootstrap your app
I'd like to suggest another sense in which you may have gone down a bad path:
you're assuming that await is paired with function*, but it could instead be
(like C#) paired with its own async-function syntactic form. Let's say for the
sake of argument that async is just a keyword that takes a
On Jan 27, 2014, at 10:58 AM, David Bruant bruan...@gmail.com wrote:
Agreed. Note that I didn't suggest to stop writing inline scripts and
proposed an alternative to script@module that can work today.
Granted, it's somewhat hacky, but I think it can work during the period
during which
On Jan 27, 2014, at 2:07 AM, David Bruant bruan...@gmail.com wrote:
Indeed. I'm wondering why we need inline script for modules.
Because people write inline scripts all the time. It's unacceptably
inconvenient not to be able to bootstrap your app with inline code. It also
allows you to
[Resending, not sure why it's not getting through to the list...]
On Jan 27, 2014, at 10:41 AM, David Herman dher...@mozilla.com wrote:
On Jan 27, 2014, at 2:07 AM, David Bruant bruan...@gmail.com wrote:
Indeed. I'm wondering why we need inline script for modules.
Because people write
Hi.
I'm trying to figure out what is the current status of ES6 especially
that next draft was released. As I understand this is not yet a
Candidate Draft this presentation mentions
http://slid.es/rafaelweinstein/tc39-process? So my question is - is
there some timetable/roadmap for the ES6?
On Jan 24, 2014, at 6:33 PM, Brendan Eich wrote:
John Barton wrote:
On Fri, Jan 24, 2014 at 12:17 PM, Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com wrote:
I should have also included:
2A) Hopefully, overtime, the old script syntactic goal will fade
from
We are pleased to announce JSCert, a formalisation of Chapters 8-14 of
the ES5 standard.
We've built JSCert using the Coq proof assistant, using the same
metaphors and data structures as the ES5 standard, and following ES5
algorithm listings line-by-line. This means we can evolve our formalism
David Herman mailto:dher...@mozilla.com
January 27, 2014 at 12:03 PM
OK, sorry I jumped in the middle of things missing some context. In
fact, I think what we've been planning on proposing is not too far --
I think -- from what you're talking about. The plan is *not* a module
attribute (that
On Jan 27, 2014 2:09 PM, David Herman dher...@mozilla.com wrote:
I'd like to suggest another sense in which you may have gone down a bad
path: you're assuming that await is paired with function*, but it could
instead be (like C#) paired with its own async-function syntactic form.
Let's say for
Could not get the example deferred function to work with traceur from the
wiki page to see what it generates.
https://github.com/google/traceur-compiler/wiki/LanguageFeatures
Been talking off list since this is off topic, but keeps coming up. I ended
up following Brendan's advice. I have a
On Jan 26, 2014, at 5:19 PM, Maciej Jaros wrote:
Hi.
I'm trying to figure out what is the current status of ES6 especially that
next draft was released. As I understand this is not yet a Candidate Draft
this presentation mentions? So my question is - is there some
timetable/roadmap for
On Sun, Jan 26, 2014 at 9:44 PM, Brendan Eich bren...@mozilla.com wrote:
David Sheets wrote:
There is no out-of-band metadata in a new script attribute. Attributes are
data, not data-about-data, and in-band in HTML.
The channel is the contents of the script element or the ES resource.
I didn't find anything in the spec on handling multiple modules with the
same name, or how to handle the redefinition of an existing module. At any
time a script type=module name=existing-nameexport default I just
replaced an exsting module;/script element could be added to the dom,
which would
On Mon, Jan 27, 2014 at 1:54 PM, Marius Gundersen gunder...@gmail.com wrote:
I didn't find anything in the spec on handling multiple modules with the
same name [...]
What should happen in such a scenario? Should existing modules be
replaced? Should an error be thrown? How would that work with
In light of the recent thread discussing async and await keywords, I
thought it'd be appropriate to raise this point again, understanding it may
be too late to make a change.
As my original post details, the concept of `return` within a generator is
surprising in its difference in behavior from
On Mon, Jan 27, 2014 at 11:08 PM, Jason Orendorff jason.orendo...@gmail.com
wrote:
On Mon, Jan 27, 2014 at 1:54 PM, Marius Gundersen gunder...@gmail.com
wrote:
I didn't find anything in the spec on handling multiple modules with the
same name [...]
What should happen in such a scenario?
Here are several ways to think about return:
- A generator function is like a normal function but it can be paused. The act
of pausing can send an intermediate value out to the caller (yield's argument)
and the caller can send an intermediate value back in when resuming (yield's
result). None
On Jan 27, 2014, at 2:18 PM, Marius Gundersen gunder...@gmail.com wrote:
So then there would be two versions of the same module, and a module could
get access to both these modules at the same time. For example, if ModuleB,
which depends on ModuleA is loaded and linked, and later ModuleA is
What is the use case for allowing registration different modules under the
same name? IMO should be an error.
jjb
On Mon, Jan 27, 2014 at 2:32 PM, David Herman dher...@mozilla.com wrote:
On Jan 27, 2014, at 2:18 PM, Marius Gundersen gunder...@gmail.com wrote:
So then there would be two
David Herman wrote:
Finally, task.js is just an example of building a control abstraction out of
iterators. It happens that the for-of control flow form is imperative and
doesn't have a use for a return value. That doesn't mean other control flow
operations won't.
+1. The need for an
Bradley Meck wrote:
Unsure on how new syntax features like await should deal w/ multiple
operands though, like if await wanted to turn multiple promises into
an array. Comma operator takes comma separated list out of the equation.
No one proposed this. Do you have a use-case? Task.js and
This is absolutely necessary for polyfilling.
Imagine that some browser has an ok-but-not-complete implementation of
the X library, but you want to use jQuery 17, which requires a better
version. You need to be able to replace X with a polyfilled update to
X, and then load jQuery on top of that.
John Lenz wrote:
1. a file extension
Talk here is not demand, and I bet we'll regret trying to add a
new one. Extensions mapped by servers to media types require
server configury, often missed or mangled. This has led in the
past to clients hardcoding, e.g.
Brendan Eich wrote:
OK, sorry I jumped in the middle of things missing some context. In
fact, I think what we've been planning on proposing is not too far --
I think -- from what you're talking about. The plan is *not* a module
attribute (that was a think-o on my part, and maybe some
On Mon, Jan 27, 2014 at 2:51 PM, Brendan Eich bren...@mozilla.com wrote:
John Lenz wrote:
1. a file extension
Talk here is not demand, and I bet we'll regret trying to add a
new one. Extensions mapped by servers to media types require
server configury, often missed
On Mon, Jan 27, 2014 at 2:50 PM, Sam Tobin-Hochstadt
sa...@cs.indiana.eduwrote:
This is absolutely necessary for polyfilling.
Imagine that some browser has an ok-but-not-complete implementation of
the X library, but you want to use jQuery 17, which requires a better
version. You need to be
On Jan 28, 2014 12:14 AM, John Barton johnjbar...@google.com wrote:
On Mon, Jan 27, 2014 at 2:50 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu
wrote:
This is absolutely necessary for polyfilling.
Imagine that some browser has an ok-but-not-complete implementation of
the X library, but you
On Mon, Jan 27, 2014 at 3:24 PM, Marius Gundersen gunder...@gmail.comwrote:
On Jan 28, 2014 12:14 AM, John Barton johnjbar...@google.com wrote:
On Mon, Jan 27, 2014 at 2:50 PM, Sam Tobin-Hochstadt
sa...@cs.indiana.edu wrote:
This is absolutely necessary for polyfilling.
John Barton wrote:
It's pretty clear from NPM experience that a new suffix is not
needed for out-of-line modules. Or are you suggesting that Node.js
lacks tooling? I'm not offended, just trying to understand.
What about the node experience helps? They have only one type of
On Mon, Jan 27, 2014 at 3:14 PM, John Barton johnjbar...@google.com wrote:
On Mon, Jan 27, 2014 at 2:50 PM, Sam Tobin-Hochstadt sa...@cs.indiana.edu
wrote:
Imagine that some browser has an ok-but-not-complete implementation of
the X library, but you want to use jQuery 17, which requires a
This is more just a comment / thinking out loud about syntax. Not related
to a specific use case. The following is just what was starting to bring my
thoughts around to that though.
I am starting to build things with the constructs in this thread, so
building out things in a similar manner to
On Mon, Jan 27, 2014 at 4:57 PM, Brendan Eich bren...@mozilla.com wrote:
John Barton wrote:
It's pretty clear from NPM experience that a new suffix is not
needed for out-of-line modules. Or are you suggesting that Node.js
lacks tooling? I'm not offended, just trying to
John Barton wrote:
On Mon, Jan 27, 2014 at 4:57 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
John Barton wrote:
It's pretty clear from NPM experience that a new suffix is not
needed for out-of-line modules. Or are you suggesting that
Sam Tobin-Hochstadt (2014-01-27 23:50):
This is absolutely necessary for polyfilling.
Imagine that some browser has an ok-but-not-complete implementation of
the X library, but you want to use jQuery 17, which requires a better
version. You need to be able to replace X with a polyfilled update
On Sat, Jan 25, 2014 at 3:31 PM, Brendan Eich bren...@mozilla.com wrote:
John Barton wrote:
The Script goal disallows 'import' and 'export' specifically to ensure
that the Script goal is inconvenient for developers and thus they are
encouraged to shift to the Module goal.
No, that's not
Allen Wirfs-Brock wrote:
The harmony proposals and old ES6 strawman wiki pages are generally
not being actively maintained.
Any already in ES6 should be prefaced by a pointer to the spec draft.
rwaldron helps with this, it is a duty we share as wiki curators, and
it's easy to edit. Copy from
Because it is js everywhere. Pick any file in an AMD/require.js system
and you can parse it.
ES6 cannot support require as a function that synchronously loads from the
filesystem, and I think you know this.
Without a new extension, you cannot import from an old-style module in
the
Kevin Smith wrote:
Because it is js everywhere. Pick any file in an
AMD/require.js system and you can parse it.
ES6 cannot support require as a function that synchronously loads
from the filesystem, and I think you know this.
Without a new extension, you cannot
John Barton wrote:
Why can't script type='module' mean If we see import/export/module
statements then we will will not evaluate the body synchronously.?
That way we avoid the jank with new code just as we do with two
parsing goals and yet we don't need two parsing goals.
We could do this,
All browsers support non media types. Can we change the specs to match
reality
On Monday, January 27, 2014 10:24:49 PM, Brendan Eich bren...@mozilla.com
wrote:
John Barton wrote:
Why can't script type='module' mean If we see import/export/module
statements then we will will not evaluate the
My argument was that Node.js has both non-module and module files with a
common suffix, .js.
Yes - but Node-modules and non-modules can be parsed the same way, so a
common extension makes sense. But when a file needs to be parsed a
different way in Node, how's that's done? By registered
On Jan 27, 2014, at 8:35 PM, Erik Arvidsson erik.arvids...@gmail.com wrote:
All browsers support non media types. Can we change the specs to match reality
Examples? What is the specified grammar?
I hope you aren't thinking of language= here.
How about fallback for old browsers?
/be
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan
Eich
Examples? What is the specified grammar?
From [the HTML spec][1]:
The `type` attribute gives the language of the script or format of the data.
If the attribute is present, its value must be a [valid MIME
Domenic Denicola wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan
Eich
Examples? What is the specified grammar?
From [the HTML spec][1]:
The `type` attribute gives the language of the script or format of the data. If the
attribute is present, its
There are three issues in my mind for tooling:
1) should the code be parsed as use strict
2) are import and export and module statements valid
3) should top level declarations be considered visible outside the file (no
can be inferred from the presence of import or exports)
It is my guess that
On Tue, Jan 28, 2014 at 2:13 AM, James Burke jrbu...@gmail.com wrote:
On Mon, Jan 27, 2014 at 3:14 PM, John Barton johnjbar...@google.com
wrote:
On Mon, Jan 27, 2014 at 2:50 PM, Sam Tobin-Hochstadt
sa...@cs.indiana.edu
wrote:
Imagine that some browser has an ok-but-not-complete
53 matches
Mail list logo
