sounds good to me, I'll update the spec. accordingly
On Aug 12, 2014, at 7:39 PM, Erik Arvidsson wrote:
symbol + '' must continue to throw.
I was suggesting that String(symbol) should not throw.
This can be spec'ed as String( value ) checking the Type of the value and
special case it in
Out of mere curiosity, why is it desired that `symbol + ''` throw?
Nathan
On Tue, Aug 12, 2014 at 10:39 PM, Erik Arvidsson erik.arvids...@gmail.com
wrote:
symbol + '' must continue to throw.
I was suggesting that String(symbol) should not throw.
This can be spec'ed as String( value )
On 8/12/14, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Aug 12, 2014, at 7:52 PM, Garrett Smith wrote:
On 8/12/14, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Aug 12, 2014, at 2:17 PM, Garrett Smith wrote:
On 8/12/14, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
[...]
As
On Wed, Aug 13, 2014 at 11:45 AM, Nathan Wall ww...@google.com wrote:
Out of mere curiosity, why is it desired that `symbol + ''` throw?
Relevant discussion:
https://github.com/rwaldron/tc39-notes/blob/c9742738ec3577d5158e8b8bfe3a46be596fef0b/es6/2013-03/mar-14.md#46-symbols
Rick
Nathan
On Aug 13, 2014, at 8:45 AM, Nathan Wall wrote:
Out of mere curiosity, why is it desired that `symbol + ''` throw?
Minimize the chance that somebody might code:
var newName = somePropertyKey+_stuff;
not realizing that somePropertyKey might be a Symbol. We don't want to
silently crete a
On Aug 13, 2014, at 8:46 AM, Garrett Smith wrote:
On 8/12/14, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Aug 12, 2014, at 7:52 PM, Garrett Smith wrote:
On 8/12/14, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Aug 12, 2014, at 2:17 PM, Garrett Smith wrote:
On 8/12/14,
On 8/12/14, 12:44 PM, Garrett Smith wrote:
If the typeof OBJECT results function then it either:
a) implements [[Call]]
That's exactly what it does. This allows making plug-in objects
callable if the plug-in decides to do so.
Since calling `Function.prototype.toString` with OBJECT as the
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 is the way
that I can't tell ES about dependencies I know about before the data is
actually fetched and instantiated. The problem can essentially be
Your example will just work if you just use
script type=module
import a;
// ...
/script
When this module is compiled the other two will be loaded and compiled.
jjb
On Wed, Aug 13, 2014 at 2:59 PM, Ian Hickson i...@hixie.ch wrote:
One of the problems I'm running into when it
On Wed, 13 Aug 2014, John Barton wrote:
On Wed, Aug 13, 2014 at 2:59 PM, Ian Hickson i...@hixie.ch wrote:
Suppose a page has this markup:
script type=module id=jquery href=jquery.js whenneeded/script
script type=module id=a href=a.js uses=jquery whenneeded/script
script
Ideally I think we should adjust the ES6 module system to support loading
and compiling code (though not necessarily executing it) for dependencies
at or around the fetch hook.
It seems like it should be possible, in principle, to add dependencies to a
load record at any time prior the
Suppose an ES6 module loads a CSS file as an import, and that CSS file has
an @import rule of its own.
The CSS @import rule semantics are such that the file must be interpreted
as CSS. It's not an open-ended import like ES6. Also, the load must not be
deduped; each style sheet that is
On Wed, 13 Aug 2014, Kevin Smith wrote:
Ideally I think we should adjust the ES6 module system to support
loading and compiling code (though not necessarily executing it) for
dependencies at or around the fetch hook.
It seems like it should be possible, in principle, to add
On Wed, Aug 13, 2014 at 3:52 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 13 Aug 2014, John Barton wrote:
On Wed, Aug 13, 2014 at 2:59 PM, Ian Hickson i...@hixie.ch wrote:
Suppose a page has this markup:
script type=module id=jquery href=jquery.js whenneeded/script
script
Andreas Rossberg wrote:
In particular,
function f(a) {
... // TDZ
let a = ...;
...
}
and
function g() {
try {
...
} catch (e) {
... // TDZ
let e = ...;
...
}
}
should be early errors because there's no useful shadowing
For prefetching we're calling LoadModule() for all the dependencies we want to
prefetch in the Fetch or Locate hooks.
For example, Systemjs has a System.depCache option which allows you to define
dependencies ahead of time. Here's the hook implementation:
If I understand what you're saying correctly, then yes (assuming that
those dependencies are also acted upon promptly, rather than only after
fetch has returned).
I see two related abilities here, and I'm not quite sure if you want one of
them or both:
1) The ability to add nodes (and
For prefetching we're calling LoadModule() for all the dependencies we
want to prefetch in the Fetch or Locate hooks.
Ah - just saw this - cool.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
18 matches
Mail list logo
