-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've been meaning to make some comments about simple modules and in
last minute with Brendan, he noted that he wanted to work with
CommonJS to make it really good, so... I think one of the key needs
that seems to be unaddressed from the current
On Thu, Nov 4, 2010 at 9:22 AM, Kris Zyp k...@sitepen.com wrote:
I believe it should be a requirement that harmony
modules (or at least a subset of them) should be desugarable into ES5
code, such that the desugared code is still a working module in
harmony engines that support native modules.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/4/2010 8:02 AM, Sam Tobin-Hochstadt wrote:
On Thu, Nov 4, 2010 at 9:22 AM, Kris Zyp k...@sitepen.com wrote:
I believe it should be a requirement that harmony
modules (or at least a subset of them) should be desugarable into ES5
code,
On Nov 4, 2010, at 6:22 AM, Kris Zyp wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've been meaning to make some comments about simple modules and in
last minute with Brendan, he noted that he wanted to work with
CommonJS to make it really good, so... I think one of the key
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/4/2010 11:13 AM, Alex Russell wrote:
On Nov 4, 2010, at 6:22 AM, Kris Zyp wrote:
I've been meaning to make some comments about simple modules and
in last minute with Brendan, he noted that he wanted to work with
CommonJS to make it
Shouldn't any var declared in the catch block be locally scoped as well?
It seems that all browsers ignore that.
try {x} catch(){ var y; } alert(y);
The above should throw an error, yet it's undefined. In fact, even if the catch
is not thrown y still exists (but if the catch block is not
On Nov 4, 2010, at 10:20 AM, Kris Zyp wrote:
the entire design space. If that is incompatible, so be it. But if the
current proposal can desugar and provide a smooth transition, why
shouldn't it? So far I am not seeing the essential incompatibility.
I repeated these points in AMWB, to what I
On Nov 4, 2010, at 10:32 AM, Peter van der Zee wrote:
Shouldn't any var declared in the catch block be locally scoped as well?
var always hoists to top of function or program. Why would it be different in a
catch block? It's not in ES3, which standardized try/catch/finally.
It seems that
On Nov 4, 2010, at 11:18 AM, Kris Zyp wrote:
I was not suggesting desugaring into CommonJS require() calls.
I know, I said to ES5. You have to desugar to something in the current ES5 +
browser APIs target.
The
transport-style API I referred to actually works similar to the
interaction
On Nov 4, 2010, at 11:32 AM, Brendan Eich wrote:
This Harmony script:
script type=harmony
var invariant = 99;
module Foo = foo;
import Foo.bar;
bar(invariant);
/script
is not equivalent to anything like this:
script
var invariant = 99;
requestModule(foo, function (Foo) {
On Nov 4, 2010, at 12:04 PM, Nathan Stott wrote:
In most languages it's great to innovate on them. In JS the equation
is not the same. In JS, any innovation won't be usable for 5+ years,
optimistically, because it will take that long for IEs that don't
support it to fade to a low enough
On Nov 4, 2010, at 12:00 PM, Peter van der Zee wrote:
I guess my confusion came from the notion that catch gets its own scope and
thinking variables in catch statements wouldn't get hoisted until the code in
that scope was entered. Thanks :)
catch did prefigure let -- lexical scope in ES3
On Nov 4, 2010, at 12:18 PM, Brendan Eich wrote:
On Nov 4, 2010, at 12:00 PM, Peter van der Zee wrote:
I guess my confusion came from the notion that catch gets its own scope and
thinking variables in catch statements wouldn't get hoisted until the code in
that scope was entered. Thanks :)
We've run into an edge case with the spread operator. What should
happen if we try to spread null or undefined?
f(...undefined);
A. Throw an error
B. Follow the path of Function.prototype.apply and others and special
case null and undefined and just call f with 0 arguments
--
erik
It would seem friendlier for the spread operator to treat it them as a empty
array otherwise you end up with code like:
if (x!=null) {
f(1,2,...x)
} else {
f(1,2)
}
On Thu, Nov 4, 2010 at 5:54 PM, Erik Arvidsson erik.arvids...@gmail.comwrote:
We've run into an edge case with the spread
On Nov 4, 2010, at 6:07 PM, John Lenz wrote:
It would seem friendlier for the spread operator to treat it them as a empty
array otherwise you end up with code like:
if (x!=null) {
f(1,2,...x)
} else {
f(1,2)
}
Yeah, null testing is a drag. People skipt it (I hear this about regexp
On Thu, Nov 4, 2010 at 9:12 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 4, 2010, at 6:07 PM, John Lenz wrote:
It would seem friendlier for the spread operator to treat it them as a
empty array otherwise you end up with code like:
if (x!=null) {
f(1,2,...x)
} else {
f(1,2)
}
On Thu, Nov 4, 2010 at 10:06 PM, Jon Zeppieri j...@bu.edu wrote:
On Thu, Nov 4, 2010 at 9:12 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 4, 2010, at 6:07 PM, John Lenz wrote:
It would seem friendlier for the spread operator to treat it them as a
empty array otherwise you end up
On Thu, Nov 4, 2010 at 10:34 PM, Jon Zeppieri j...@bu.edu wrote:
On Thu, Nov 4, 2010 at 10:06 PM, Jon Zeppieri j...@bu.edu wrote:
On Thu, Nov 4, 2010 at 9:12 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 4, 2010, at 6:07 PM, John Lenz wrote:
It would seem friendlier for the spread
On Thu, Nov 4, 2010 at 10:48 PM, Jon Zeppieri j...@bu.edu wrote:
Spread-as-rest-arg-syntax constructs an array. Spread-as-operator splices
the elements of an array into an argument list.
So, if a spread operator expression: ...null splices zero values into an
argument list, then its
20 matches
Mail list logo
