On Fri 14 Jun 2013 04:24, Luke Hoban lu...@microsoft.com writes:
(I believe this introduces the only place that var x is allowed but
cannot have an initializer?).
FWIW, there are similar situations in the same spot of the grammar: let
x can't have an initializer in for-of or for-in, and
Le 14/06/2013 02:37, Mark S. Miller a écrit :
Other things being equal, or even close, I am always in favor of specs
being more deterministic.
Even with this pinned down, we should still allow implementations to
switch among different algorithms based on the size of the array, the
cache
Le 14/06/2013 09:55, Andreas Rossberg a écrit :
On 14 June 2013 09:50, David Bruant bruan...@gmail.com wrote:
And this particular behavior might be standardizable without a loss (even
with a gain), because:
1) a sort algorithm only needs all the array values once at least once
(serie of
Thanks to proxies now having a separate trap for “invoke”, we can automatically
bind methods on “get”. I’ve written down my thoughts here:
http://www.2ality.com/2013/06/auto-binding.html
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog:
On Fri, Jun 14, 2013 at 3:48 AM, Andreas Rossberg rossb...@google.com wrote:
What about:
// M.js
export * from foo;
export * from foo;
// foo.js
export var x = 1;
Or:
// M.js
export * from foo;
export * from bar;
// foo.js
export * from
On Fri, Jun 14, 2013 at 4:57 AM, Claus Reinke claus.rei...@talk21.com wrote:
This is a static error.
On Thu, Jun 13, 2013 at 3:37 PM, Kevin Smith zenpars...@gmail.com wrote:
Take the following situation:
// M.js
export * from foo;
export * from bar;
I am confused: I thought
On Fri, Jun 14, 2013 at 4:30 AM, Andreas Rossberg rossb...@google.com wrote:
On 14 June 2013 10:17, David Bruant bruan...@gmail.com wrote:
I'm suggesting to make the [[Get]], [[Put]] and [[Delete]] sequence less
implementation-dependent which means at least to bound them to the maximum
of what
// M.js
export * from foo;
export * from bar;
// foo.js
export * from foobar;
// bar.js
export * from foobar;
// foobar.js
export var x = 1;
I just want to make sure that using M.x in any of these cases is an
error likewise.
Is there a
I am confused: I thought import * was removed because, in the
presence of dynamically configured loaders, it would leave tools
(and programmers) unable to infer the local scope without executing code.
Now we have the same issue back via export *, just need a re-exporting
intermediate module?
@@create allows you to set up instance prototypes, here's an amended
version of your example code using ES6 classes:
https://gist.github.com/anba/9f0acbb29bf755d26f37
The updated version also gets rid of the origProto workaround, but
requires a custom @@hasInstance hook. I've tested the
On Fri, Jun 14, 2013 at 9:43 AM, Andreas Rossberg rossb...@google.com wrote:
On 14 June 2013 14:11, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Fri, Jun 14, 2013 at 4:30 AM, Andreas Rossberg rossb...@google.com
wrote:
I don't see much of a use case for an array with getters, let alone
I'm using ES6 generators to implement a little async/await library and I'm
quite pleased with the result so far but I'm lacking one API: a function to
get stack information from a generator object. Ideally it would return the
name of the current generator function, the filename and the line number
While playing with my little async/await library, I noticed that I was
often forced to parenthesize yield expressions as (yield exp) because of
the low precedence of the yield operator. Typical patterns are:
var foo = (yield a()) + (yield b()) + (yield c());
if ((yield a()) cond2 ...) ...
Looks
On Fri, Jun 14, 2013 at 5:12 PM, Bruno Jouhier bjouh...@gmail.com wrote:
While playing with my little async/await library, I noticed that I was often
forced to parenthesize yield expressions as (yield exp) because of the low
precedence of the yield operator. Typical patterns are:
var foo =
On Fri, Jun 14, 2013 at 11:21 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Using generators for async is a clever hack, but it's just a hack. A
proper solution will need a new keyword anyway (most languages seem to
use await or something similar), which can get the better
precedence.
This
On Fri, Jun 14, 2013 at 5:33 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Fri, Jun 14, 2013 at 11:21 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Using generators for async is a clever hack, but it's just a hack. A
proper solution will need a new keyword anyway (most languages seem to
On Jun 14, 2013, at 12:01 AM, Andy Wingo wrote:
On Fri 14 Jun 2013 04:24, Luke Hoban lu...@microsoft.com writes:
(I believe this introduces the only place that var x is allowed but
cannot have an initializer?).
FWIW, there are similar situations in the same spot of the grammar: let
x
Bruno Jouhier wrote:
While playing with my little async/await library, I noticed that I was
often forced to parenthesize yield expressions as (yield exp) because
of the low precedence of the yield operator. Typical patterns are:
var foo = (yield a()) + (yield b()) + (yield c());
That's
Andy Wingo wrote:
On Fri 14 Jun 2013 04:24, Luke Hobanlu...@microsoft.com writes:
(I believe this introduces the only place that var x is allowed but
cannot have an initializer?).
FWIW, there are similar situations in the same spot of the grammar: let
x can't have an initializer in for-of
I think that's possible since the beginning of the time ... we just need
to be a bit more pragmatic with what's available.
Examples here:
http://webreflection.blogspot.com/2012/11/my-name-is-bound-method-bound.html
summarized as
```javascript
Generic.prototype.bound = function (methodName) {
Alex Russell wrote:
This, incidentally, is the sort of way I'd hoped we'd slot in
soft-binding.
I still do not know how to do soft binding with acceptable
implementation cost. But anyway, this seems like very hard binding. How
would you rebind |this|, ever?
/be
On Fri, Jun 14, 2013 at
The current precedence looks natural to me for a yield but less when yield
is used as an await keyword. That's why I proposed to handle it with a
different keyword rather than by changing yield's precedence. Await would
have been a good candidate but it is not reserved.
Anyway, I don't want to
Le 14/06/2013 16:56, Bruno Jouhier a écrit :
I'm using ES6 generators to implement a little async/await library and
I'm quite pleased with the result so far but I'm lacking one API: a
function to get stack information from a generator object. Ideally it
would return the name of the current
I suppose a special binding operator has already been discussed and discarded?
const functionBoundToclassInstance = classInstance-methodName
and everytime classInstance-methodName is called it gets returned the
same function
meaning references don't have to be stored for unsubscribing from
On Fri, Jun 14, 2013 at 4:26 PM, Brian Di Palma off...@gmail.com wrote:
I suppose a special binding operator has already been discussed and
discarded?
const functionBoundToclassInstance = classInstance-methodName
A thin arrow here will be confusing in the fat-arrow ES6-world-of-tomorrow;
This is a familiar discussion from C#. I forwarded it to the mediator of
that convresation and got a nice summary, pasted here:
-- Forwarded message --
From: Mads Torgersen mads.torger...@microsoft.com
Date: Fri, Jun 14, 2013 at 2:11 PM
Subject: RE: Precedence of yield operator
Thanks David. The problem is that I need it first in node.js, and if
possible with a standardized API that works in all ES6 JS engines.
I see this as being similar to asking for a portable stack property in
Error objects. I don't know if it is actually mandated by ES6 but it looks
like all major
I don’t know if a similar thing is possible in EcmaScript. But I believe
that a low-precedence yield as a substitute for a high-precedence await is
problematic: you never want “yield a + yield b” to mean “yield (a + (yield
b))”: the things you await – Task, Promises, Futures, whatever you call
If I understand this right, essentially the problem is that an exception
could occur when some of the involved code is not alive on the stack
(because the generator(s) are suspended), and without the ability to
capture this information, the end user has no actual knowledge of why the
exception
To answer Brian's question, yes: already discussed an in strawman space
on the wiki, awaiting promotion to harmony, maybe for ES7:
http://wiki.ecmascript.org/doku.php?id=strawman:bind_operator
/be
Rick Waldron wrote:
On Fri, Jun 14, 2013 at 4:26 PM, Brian Di Palma off...@gmail.com
This is all on the agenda for ES7. It cleanly missed ES6 in May 2011(!).
https://mail.mozilla.org/pipermail/es-discuss/2011-May/014748.html
/be
Dean Tribble wrote:
This is a familiar discussion from C#. I forwarded it to the mediator
of that convresation and got a nice summary, pasted here:
Andreas Rossberg wrote:
On 13 June 2013 23:40, Brendan Eichbren...@mozilla.com wrote:
I think V8 has a de-facto bug to fix. I'm ok with requiring stability as a
normative property of Array.prototype.sort given such a V8 bugfix.
IIUC, current IE versions are not been stable either, so calling
Claude Pache wrote:
Yes, the name of the contract is `@@iterator`. A for/of loop is normally used
to loop over an entire collection of items, so it is expected that the user
provides an object from which one could extract a fresh (i.e. non-consumed)
iterator. In order to enforce that
33 matches
Mail list logo
