2014-06-13 19:21 GMT+02:00 Allen Wirfs-Brock al...@wirfs-brock.com:
Anotherconcern I have with @@new, it that it exposes two extension points,
@@new and @@create, on very constructor. I'm afraid that it wouldn't be
very clear to most ES programmers when you should over-ride one or the
other.
What's the current status on proposals for Function.create?
At present the inability to set a prototype on a Function instance is
a real hindrance to creating objects that are both new()-able and have
properties. The same goes for creating callable objects that happen to
have properties or
On 13 June 2014 18:23, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
We could consider special cases loop bodies that are BlockStatements and
statically reject those that contain declaration that shadow the loop
declarations. However, I think it is probably best to leave that sort of
Hi Katelyn,
If you intend to have a constructor that inherit from another one, it is
possible in ES6: just recall that, in ES, constructors and classes happen to be
the same thing:
class C extends D { // alternatively: let C = class extends D {
constructor(...) { ... }
They curly braces only look like destructuring if you keep the name the
same, when imported with a different name it's a slightly different syntax,
{oldname as newname} not {oldname: newname}, also as it currently stands
// BAD
import lib from 'library';
lib.foo();
lib.bar();
is
On Monday, June 16, 2014 12:33 AM, Axel Rauschmayer a...@rauschma.de wrote:
**Single-export modules.** Still missing is support for single-export modules,
which could be added as follows (the keyword `default` instead of the asterisk
works just as well, in my opinion).
You're being
On Sun, Jun 15, 2014 at 8:32 PM, Axel Rauschmayer a...@rauschma.de wrote:
I apologize for this email, but I still don’t understand the current
module design.
...
**Single-export modules.** Still missing is support for single-export
modules, which could be added as follows (the keyword
On Mon, Jun 16, 2014 at 3:06 AM, Katelyn Gadd k...@luminance.org wrote:
emscripten/asm.js) will face similar issues. The other compilers I've
seen that tackle this solution efficiently do so by abandoning the
'new' keyword in favor of magic methods, which I consider a poor
solution.
I'd be
On Jun 15, 2014, at 11:45 PM, Tom Van Cutsem wrote:
2014-06-13 19:21 GMT+02:00 Allen Wirfs-Brock al...@wirfs-brock.com:
Anotherconcern I have with @@new, it that it exposes two extension points,
@@new and @@create, on very constructor. I'm afraid that it wouldn't be very
clear to most ES
On Mon, Jun 16, 2014 at 8:53 AM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
They curly braces only look like destructuring if you keep the name the
same, when imported with a different name it's a slightly different syntax,
{oldname as newname} not {oldname: newname}, also as it currently
e.g. something like
https://gist.github.com/calvinmetcalf/9252f41bf6e3c8b4add7
On Mon, Jun 16, 2014 at 1:01 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
On Mon, Jun 16, 2014 at 8:53 AM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
They curly braces only look like destructuring if you
From: es-discuss es-discuss-boun...@mozilla.org on behalf of C. Scott Ananian
ecmascr...@cscott.net
Using destructuring syntax for imports would be a *good thing*. It builds on
our existing understanding of JS constructs, instead of adding more
gratuitously different things to learn.
This
On Jun 16, 2014 1:06 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
From: es-discuss es-discuss-boun...@mozilla.org on behalf of C. Scott
Ananian ecmascr...@cscott.net
Using destructuring syntax for imports would be a *good thing*. It
builds on our existing understanding of JS
On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
e.g. something like
https://gist.github.com/calvinmetcalf/9252f41bf6e3c8b4add7
re:
let { foo, bar } = import library;
Ignoring the UnaryExpression ambiguity, what happens here:
// library.js
export const
I'm not talking about MIO properties. I'm talking about the bindings created by
import declarations.
From: Sam Tobin-Hochstadtmailto:sa...@cs.indiana.edu
Sent: 2014-06-16 13:21
To: Domenic Denicolamailto:dome...@domenicdenicola.com
Cc: Calvin
I wonder if it would help reduce confusion if the syntax wasn't so similar
to destructuring:
import ( foo, bar ) from library;
or
import foo, bar from library;
- Matthew Robb
On Mon, Jun 16, 2014 at 10:24 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
I'm not talking about
A good question Rick, I sketched that out pretty quickly earlier today. It
did take me a while to remember that modules are the ONE place where
strings are by reference an not by value...
On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Mon, Jun 16, 2014 at
On Mon, Jun 16, 2014 at 1:06 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: es-discuss es-discuss-boun...@mozilla.org on behalf of C. Scott
Ananian ecmascr...@cscott.net
Using destructuring syntax for imports would be a *good thing*. It builds
on our existing understanding of
On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
e.g. something like
https://gist.github.com/calvinmetcalf/9252f41bf6e3c8b4add7
re:
let { foo, bar } = import library;
Ignoring
Jasper: none of those things are legal in the current spec
On Mon, Jun 16, 2014 at 1:41 PM, Jasper St. Pierre jstpie...@mecheye.net
wrote:
On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf calvin.metc...@gmail.com
On Mon, Jun 16, 2014 at 1:41 PM, C. Scott Ananian ecmascr...@cscott.net wrote:
That is, IMHO mutable bindings and modules with cyclic dependencies
are members of the bad parts of JavaScript. Sure, sometimes there's
a valid reason to use them. But for most developers they will be
happier
On Mon, Jun 16, 2014 at 1:40 PM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
A good question Rick, I sketched that out pretty quickly earlier today.
It did take me a while to remember that modules are the ONE place where
strings are by reference an not by value...
It's more than
On Mon, Jun 16, 2014 at 1:41 PM, Jasper St. Pierre jstpie...@mecheye.net
wrote:
On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
e.g. something like
A few more thoughts...
On Mon, Jun 16, 2014 at 1:41 PM, Jasper St. Pierre jstpie...@mecheye.net
wrote:
On Mon, Jun 16, 2014 at 1:22 PM, Rick Waldron waldron.r...@gmail.com
wrote:
On Mon, Jun 16, 2014 at 1:05 PM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
e.g. something like
Yes! Don't make it look like destructuring and then say it's nothing like
that.
At this point I'd be happy to be able to only get back one thing from an
import (no destructure-like syntax) that could be any kind of value,
including an object with lots of methods on it like we are used to in
My argument is that you can keep everything the same as it is now but
change the syntax to not use curlies and avoid the confusing similarity to
destructuring. You could use `(a,b,c)` or `a,b,c` and it would all
continue working as it does but be less confusing.
- Matthew Robb
On Mon, Jun 16,
Thanks for the clarification, one detail about the order between
incrementing and setting $$lastIteration_i:
{
let i = $$lastIteration_i; //create and initialize per iteration i
if (!(i10)) break;
{
let i;
}
*i++;
$$lastIteration_i = i;*
}
Should it be*
On Mon, Jun 16, 2014 at 2:27 PM, Matthew Robb matthewwr...@gmail.com wrote:
My argument is that you can keep everything the same as it is now but change
the syntax to not use curlies and avoid the confusing similarity to
destructuring. You could use `(a,b,c)` or `a,b,c` and it would all
On Jun 16, 2014, at 11:29 AM, Michael Zhou wrote:
Thanks for the clarification, one detail about the order between incrementing
and setting $$lastIteration_i:
{
let i = $$lastIteration_i; //create and initialize per iteration i
if (!(i10)) break;
{
let i;
}
i++;
- Matthew Robb
On Mon, Jun 16, 2014 at 11:42 AM, C. Scott Ananian ecmascr...@cscott.net
wrote:
On Mon, Jun 16, 2014 at 2:27 PM, Matthew Robb matthewwr...@gmail.com
wrote:
My argument is that you can keep everything the same as it is now but
change
the syntax to not use curlies and avoid
Another alternative is to introduce this funny binding not
destructing behavior as a first-class language construct, so that one
could do:
```
let o = { f: 1 };
let f = o; // using your angle-bracket syntax for the sake of discussion
o.f = 2;
console.log(f); // prints '2'
let foo = import
I have suggested alterations to the modules effort, and an in-progress
prototype[1].
It is based on field usage of existing JS module systems, and my work
supporting AMD module solutions for the past few years.
There is a document describing what it attempts to fix[2]. The table
of contents from
The other big concern here is that in production, very few people are going
to be loading every JavaScript file asynchronously. If there's magic,
there needs to be a reasonable way to handle bundling multiple ES6 files
together.
The [current solution][1] turns it into common.js (or others) and
On Fri, Jun 13, 2014 at 5:33 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
Interesting. It'd be nice if we could further simplify the Proxy/Reflect
API. Given the local nature of these changes, we might still include it in
ES6 if we achieve quick consensus.
I'm mostly interested in getting rid
The other big concern here is that in production, very few people are
going to be loading every JavaScript file asynchronously. If there's
magic, there needs to be a reasonable way to handle bundling multiple ES6
files together.
OK, so there are two issues here:
1. How do you bundle
On Jun 16, 2014, at 5:41 PM, Frankie Bagnardi f.bagna...@gmail.com wrote:
The other big concern here is that in production, very few people are going
to be loading every JavaScript file asynchronously. If there's magic, there
needs to be a reasonable way to handle bundling multiple ES6
On Jun 16, 2014, at 3:02 PM, Jason Orendorff wrote:
On Fri, Jun 13, 2014 at 5:33 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
Interesting. It'd be nice if we could further simplify the Proxy/Reflect
API. Given the local nature of these changes, we might still include it in
ES6 if we achieve
Claude: Thanks, I was under the impression that existing ES6 class
inheritance wouldn't allow this to work. If it does, that's a big
improvement and I'll have to try it once class syntax is working in
one of the browsers I target.
Scott: The problem isn't a 'sync issue'; the body of the function
On Mon, Jun 16, 2014 at 3:42 PM, caridy car...@gmail.com wrote:
On Jun 16, 2014, at 5:41 PM, Frankie Bagnardi f.bagna...@gmail.com
wrote:
The other big concern here is that in production, very few people are
going to be loading every JavaScript file asynchronously. If there's
magic, there
I thought SPDY was, to quote wikipedia, about: reducing web page load
latency and improving web security
How does SPDY help when the issue is lots of small requests ping ponging back
and forth between client and server?
SPDY multiplexes the requests across the same connection, which is
It turns out there are a number of sites (such as mobile.twitter.com) that are
property detecting .entries on objects, and that means that they're breaking
when Array.prototype.entries is provided.
We're removing it from JSC now, until we can find a way to expose it without
causing site
That is why you need to implement @unscopables too.
On Jun 16, 2014 7:08 PM, Oliver Hunt oli...@apple.com wrote:
It turns out there are a number of sites (such as mobile.twitter.com)
that are property detecting .entries on objects, and that means that
they're breaking when
On Mon, Jun 16, 2014 at 4:08 PM, Oliver Hunt oli...@apple.com wrote:
It turns out there are a number of sites (such as mobile.twitter.com) that
are property detecting .entries on objects, and that means that they're
breaking when Array.prototype.entries is provided.
What are they using the
All major browsers (including safari) support SPDY today. But the point
is, we should not consider bundling as a prime use-case for modules,
because it is not going to be important at all.
I agree, in principle, but I'm not quite as confident that bundling will
have *no* place on the web.
@@unscopeable doesn't work as they are not using |with|
The logic is something along the lines of
if (foo.entries) ...
It looks like there are paths that objects or arrays may path through, with
entries being a perfectly reasonable property name in the object case, but
now the array case
On Mon, Jun 16, 2014 at 4:04 PM, caridy car...@gmail.com wrote:
I thought SPDY was, to quote wikipedia, about: reducing web page load
latency and improving web security
How does SPDY help when the issue is lots of small requests ping ponging
back and forth between client and server?
SPDY
I thought SPDY was, to quote wikipedia, about: reducing web page load
latency and improving web security
How does SPDY help when the issue is lots of small requests ping ponging
back and forth between client and server?
SPDY multiplexes the requests across the same connection, which
The latency problem caused by tree depth can also be solved with a Link
prefetch header (when Chrome re-enables this) from a server trace or a
simple loader extension that contains a traced dependency cache. Injecting
a trace tree is a much simpler and better alternative to bundling as we get
the
Guy Bedford and I have been discussing a compromise with bundling of
“internal” dependencies but leaving “external” dependencies out of the
bundle. There are legitimate concerns around exposing a library’s internal
module structure to the outside world. For example, Ember is written using
ES6
Apparently, this problem was already known more than 4 months ago:
https://bugzilla.mozilla.org/show_bug.cgi?id=924386#c19
I guess it specifically affect the mobile web? for it didn't prevent Firefox to
ship `Array.prototype.entries` in v28, released on March 18.
—Claude
Le 17 juin
On Mon, Jun 16, 2014 at 4:49 PM, caridy car...@gmail.com wrote:
I thought SPDY was, to quote wikipedia, about: reducing web page load
latency and improving web security
How does SPDY help when the issue is lots of small requests ping
ponging back and forth between client and server?
SPDY
You don't really want 300/3000/3 modules where you have to load,
parse, then request (dependencies). You really need your dependencies,
pre-ordered and pre-loaded (that is bundled) if you want your empty cache
clients to get a good experience. SPYD is only one piece of a puzzle it
isn't a
This is a gently reminder I don't represent my company anyhow in this
mailing list but actually I've been working on mobile web here at twitter
for 1.5 years how ... thanks for the report, I'll do what I can (already
patched, waiting reviews) + I don't think mobile web should block anyhow
new
On Mon, Jun 16, 2014 at 5:39 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Perhaps you could fill out what you actually mean by @@new and how it would
work for regular functions, class declarations, and subclasses of both
regular classes and the legacy built-ins.
Yes, that's a very good
Would .items fare better, I wonder.
/be
Oliver Hunt wrote:
It turns out there are a number of sites (such as mobile.twitter.com
http://mobile.twitter.com) that are property detecting .entries on
objects, and that means that they're breaking when
Array.prototype.entries is provided.
We're
John, there are a couple of solutions at hand that you can apply:
1. loader provides the right hooks for you to hint at loader what are the
modules you need to need to load. which is literally 10 lines of code for an
extension of the loader:
56 matches
Mail list logo
