From: David Bruant [bruan...@gmail.com]
Especially given that it's only for a transitioning period where native (or
polyfilled) have to cohabit with previous library promises?
This is a really bad misconception that you have repeated several times now.
DOM Futures, and possibly ECMAScript
From: Sam Tobin-Hochstadt [sa...@ccs.neu.edu]
I don't see what the point of `await` is in your gist. It looks like all of
the work is being done by `function^`, which looks to be sugar for creating a
function and passing it to a scheduler like `Q.async` or `taskjs.spawn`. We
could add
From: sam...@gmail.com [sam...@gmail.com]
What exactly would be the semantic difference between this and just using
'yield'?
You mean, if you replaced my example by
```js
function*^ doubleSomeNumbers() {
const numbers = yield getNumbersToDouble();
for (var i = 0; i numbers.length; ++i)
This looks lovely.
The only thing I'd want to add: we need integers! And generally better numeric
types. From speaking to developers on the ground, this is the biggest missing
language feature they see (that isn't already addressed in ES6). I know Brendan
has made some moves in this direction
From: Mark S. Miller [erig...@google.com]
GC is never required to be complete. We must allow the collector to not
collect some unreachable objects. This means that, without .done, there's no
guarantee that an unseen-rejection bug will ever get diagnosed. Therefore we
still need .done.
I
One bigger question: what is the DOM use case for event streams?
That is, it's very clear what the DOM use cases are for binary data streams.
(Most urgently, streaming XHR, but also perhaps unifying the many interfaces
that use object URLs as a means of connecting separate streams of data; also
with `yield` and task.js-style wrappers.
-Original Message-
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
Sent: Thursday, April 18, 2013 21:34
To: Domenic Denicola
Cc: es-discuss
Subject: Re: DOM EventStreams (take two on Streams): Request for
feedback
On Thu, Apr 18, 2013 at 5:11
I think a large part of the confusion here is that when Tab says streams he
really means observables or signals. As you point out, this would be
completely inappropriate as a stream API, as it does indeed ignore many of the
lessons Node learned. Surprisingly, it doesn't seem to draw on any of
From: Tab Atkins Jr. [mailto:jackalm...@gmail.com]
I do somewhat resent the implication that I invented something wholly new
without drawing on any existing APIs. I looked at the syntaxes of several
similar APIs in other languages while designing this, and took lessons from
them.
In
I notice that operations accepting positive integers do various
somewhat-inconsistent things as of the latest ES6 spec:
Various typed array things do `ToPositiveInteger`, a new operation as of ES6:
- `ArrayBuffer(length)` and `TypedArray(length)`
- Constructing a typed array, and
From: Nebojša Ćirić [c...@google.com]
Since we (i18n) already have timezone data for date formatting, we could do
what we did for Date.prototype.toLocaleDateString and extend say
Date.prototype.getTimezoneOffset method to support timezone parameter.
This sounds amazing. Please do this.
To
From: Nebojša Ćirić [c...@google.com]
That's correct. We may need reverse too - for given UTC epoch milliseconds
(or minutes after UTC Date) tell me what the date components would be in a
given timezone.
Hmm, so:
```js
var date = new Date(utcMilliseconds);
var monthInNewYork =
Should this be added to test-262?
It'd be cool if test-262 took pull requests :).
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Yusuke SUZUKI
Sent: Monday, April 1, 2013 22:44
To: Allen Wirfs-Brock
Cc: es-discuss@mozilla.org
Subject: Re: RegExp Flags
From: Rick Waldron [waldron.r...@gmail.com]
TC39 reached consensus on the inclusion of WeakSet, though it needs to be
designed:
https://github.com/rwldrn/tc39-notes/blob/master/es6/2012-09/sept-19.md#weakset
Is this ES6 timeframe, or ES7? I have run into a few use cases for it since
hearing
Such a situation should only be possible within modules (via a custom loader),
from my understanding. In which case you’re going to be in strict mode anyway,
so yes, it’s definitely `undefined`.
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Axel
On Mar 18, 2013, at 7:54, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Sun, Mar 17, 2013 at 11:44 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
1. implicit global variable creation
2. `with`
3. `delete`ing free variables
4. `eval` introducing local bindings
2 and 4 make
From: Sam Tobin-Hochstadt
On Mon, Mar 18, 2013 at 8:40 AM, Andreas Rossberg rossb...@google.com wrote:
Nothing, but Sam probably meant to write:
if (something_random()) xxx = 7;
xxx; // ReferenceError or not?
Right, I was confusing the problem this code describes, which is what I think
I went back to this old es-discuss thread:
http://www.mail-archive.com/es-discuss@mozilla.org/msg18408.html
which references a video segment from Mark Miller:
http://www.youtube.com/watch?v=Kq4FpMe6cRst=42m53s
giving four static scoping violations:
1. implicit global variable creation
2.
I think this thread is the most recent discussion of the issue:
http://esdiscuss.org/topic/1944
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Angus Croll [anguscr...@gmail.com]
Sent: Monday, March 11, 2013 17:08
To: Rick
From: Dean Landolt
The leakage is that caller is a reference -- having that reference gives you
the capability to follow any further references on its object graph. This
reference wasn't explicitly handed out (as is always the case with
this-binding in call, apply and bind) -- it was just
From: Andrea Giammarchi
if I do not return that function explicitly and since I own that function
being the one that put a `caller` inside it where is exactly the problem ...
once again?
If I've passed that object I could also argue that object should not be
modified until I decide.
Trans-compiling works for 99% use-cases that aren't extending built-ins.
Or using class-side inheritance in a non-__proto__ environment. (That's
probably still within the 1%, admittedly.)
Also, I thought super was fairly magical? E.g. how it gets associated to
methods? Not very sure though,
You can transpile statics although, again, not entirely faithfully, by
putting the statics on each of the inheriting constructors. Not quite the
same...it's these little details I was referring to. They start to add up
Agreed. I've been trying to file such little details against Traceur [1],
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Rick Waldron [waldron.r...@gmail.com]
Thanks, I've submitted an agenda item that includes _both_ find and findIndex.
Awesome!
One issue with `find` is what distinguishes
find([1, 2, 3], x = isNaN(x)); //
Oooh, static getters and setters, nice.
Glad to see the max-min idea seems to be working out well :). Little
incremental improvements like this seem natural and a joy to use. Awesome to
see them in Traceur so quickly too!
From:
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Oliver Hunt [oli...@apple.com]
For now I would say that we shouldn't expose the internal implementation
behaviour of yield (which is what being able to explicitly create or call a
generator produces). That
-Original Message-
From: Brendan Eich [mailto:bren...@mozilla.com]
Sent: Sunday, February 10, 2013 03:20
Changing from hasMore/getNext to current/moveNext does not eliminate two
methods that can get out of sync. You can imagine one is a property, not a
method, but the general case
From: Brendan Eich [mailto:bren...@mozilla.com]
Domenic Denicola wrote:
-Original Message-
From: Brendan Eich [mailto:bren...@mozilla.com]
Sent: Sunday, February 10, 2013 03:20
Changing from hasMore/getNext to current/moveNext does not eliminate two
methods that can get
I know `StopIteration` is pretty baked in by now. But, most of the arguments I
can recall for it are that it’s better than `hasNext` + `next`, wherein you
have to keep two methods in sync. I saw the Dart iterator API the other day and
it provided a third alternative I thought the list might
The fact that ES built-ins' methods are defined on the prototype **and** have
access to private data seems to indicate that the ideal model would allow
both. WeakMaps do, to a degree, permit both, but it's just a hack. If it
wasn't, the ES spec itself would describe built-ins' private data
I think part of the confusion is that, from what I understand, harmony refers
to things that are agreed upon by all TC39 members, or at least were at one
time. But this does not imply it being in ES6.
That is, much confusion I've seen on the internet stems from people assuming
harmony means
Dude, do you even read the spec?
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.14.5.4
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Thaddee Tyl [thaddee@gmail.com]
Sent: Thursday, January 17, 2013
If we’re making up new syntax, I think this would be much nicer if “private.x”
were spelled “this.@x” and “private(x)” were spelled “x.@”
Also, I don’t see why constructors need to use the “private.x” syntax whereas
other methods get to use the free variable?
With these in mind I give the
Coincidentally, I compiled a list of interesting cases a few days ago, for both
const and let. They were meant to be used in kangax's ES6 compatibility table:
https://github.com/kangax/es5-compat-table/issues/58
In short:
const x; // SyntaxError
let x; let x; // SyntaxError
const x = 5; const
It's funny: I've been considering a similar thread, but the opposite. I.e.
private symbols better than weak maps?
In particular, given the freezing clarification, the use cases for weak maps
instead of private symbols seem to reduce to adding *new* symbols to
extension-prevented objects.
Is
From: Brandon Benvie [bran...@brandonbenvie.com]
Sent: Thursday, January 10, 2013 11:50
They both have their place since there's many uses for both inherited and
non-inherited private values.
Of course, (non-)inheritance is a great point.
Amusingly, using conventional OO terminology, it
Really?? http://people.mozilla.org/~jorendorff/es6-draft.html#sec-15.15.5
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Rick Waldron [waldron.r...@gmail.com]
Sent: Thursday, January 10, 2013 14:57
To: Nathan Wall
Cc:
In addition to Brandon's points, it seems to me a clear win from the say what
you mean angle.
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Axel Rauschmayer [a...@rauschma.de]
Sent: Tuesday, January 08, 2013 15:13
To:
More likely, knowing our friendly neighborhood JIT-coders, Maps which only
contain string keys will be optimized under the hood.
From: Axel Rauschmayer [a...@rauschma.de]
Sent: Tuesday, January 08, 2013 16:01
To: Domenic Denicola
Cc: es-discuss list
Subject: Re
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org]
On Behalf Of Axel Rauschmayer
Sent: Sunday, December 30, 2012 16:22
9c) using methods as callback functions
The single biggest feature on my ES7 wishlist is the bind operator strawman:
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org]
On Behalf Of Anne van Kesteren
Sent: Sunday, December 30, 2012 17:18
On Sun, Dec 30, 2012 at 10:22 PM, Axel Rauschmayer a...@rauschma.de wrote:
5. Array-like objects [not completely fixed (DOM...), but
Duplicate parameters are quite common in the following case:
callSomething(function (_, _, whatIActuallyCareAbout) {});
From: Brendan Eichmailto:bren...@mozilla.com
Sent: 12/29/2012 20:16
To: Mark S. Millermailto:erig...@google.com
Cc:
29, 2012 22:10
To: Domenic Denicola
Cc: Mark S. Miller; es-discuss@mozilla.org
Subject: Re: excluding features from sloppy mode
Domenic Denicola wrote:
Duplicate parameters are quite common in the following case:
callSomething(function (_, _, whatIActuallyCareAbout) {});
I've never
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org]
On Behalf Of Brendan Eich
Sent: Sunday, December 30, 2012 00:06
by yoking ES6 feature adoption to strict mode adoption, you multiply risks
and reduce ES6 adoption.
I'd like to lend a little bit of defense to
On Dec 28, 2012, at 7:36, David Bruant bruan...@gmail.com wrote:
Le 28/12/2012 13:32, Anne van Kesteren a écrit :
On Fri, Dec 28, 2012 at 12:51 PM, Andreas Rossberg rossb...@google.com
wrote:
That's a good point, actually. I, for one, do not understand the criteria by
which we chose to
Now that I have fully digested Andreas's points from the earlier thread on
modules [1], I am a bit concerned about the implications of `import`
introducing aliasing bindings. To recap, the situation is:
module foo {
export let state = 5;
export function modifyState() {
state = 10;
};
}
On Dec 28, 2012, at 11:19, Andreas Rossberg
rossb...@google.commailto:rossb...@google.com wrote:
On 28 December 2012 16:20, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote:
Finally, I can't shake the feeling I'm missing something. Why is this aliasing
On Dec 28, 2012, at 11:54, David Herman dher...@mozilla.com wrote:
On Dec 28, 2012, at 8:32 AM, Domenic Denicola dome...@domenicdenicola.com
wrote:
Dave and Sam may have a different answer, but I'd answer that the aliasing
semantics follows from a module system's role as (among other
On Dec 28, 2012, at 12:28, David Herman dher...@mozilla.com wrote:
Another example where this could come up is initialization. Since imports
tend to be at the beginning of a module, you could end up reading the value
of a not-yet-initialized variable too soon.
A code example of this would
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org]
On Behalf Of David Herman
Sent: Wednesday, December 26, 2012 19:50
I imagine your reply is: don't do that transformation; place your `let`
declarations as late as possible before they are going to be used. I
On Dec 20, 2012, at 19:02, David Herman dher...@mozilla.com wrote:
On Dec 20, 2012, at 1:29 PM, Brendan Eich bren...@mozilla.com wrote:
So the particular approach -- in particular -- that you are questioning is
adding export = to ES6 modules. I agree it is ad-hoc. It also seems likely
to
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss- boun...@mozilla.org]
On Behalf Of Brendan Eich
Sent: Wednesday, December 19, 2012 23:11
In a thread you may not have caught up on, Andreas did argue for a special
form such as
module foo at foo;
for
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Anne van Kesteren [ann...@annevk.nl]
Sent: Monday, December 17, 2012 09:56
By types I mean e.g. constraining set() to just accept strings.
I think the JavaScript-y way of doing this, as exemplified in the ES5
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org]
On Behalf Of Brendan Eich
Sent: Saturday, December 15, 2012 14:26
Reflecting var and function bindings on window (or |this| or |self| or other
aliases) as configurable properties, but refusing to allow
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on
behalf of Nathan Wall [nathan.w...@live.com]
Sent: Friday, December 14, 2012 13:34
On another note, I do sort of wonder why `Number.isNaN` is coming into the
language now at the same time as the `is` operator and
-Original Message-
From: Andreas Rossberg [mailto:rossb...@google.com]
Sent: Thursday, December 6, 2012 11:31
On 6 December 2012 16:44, Domenic Denicola
dome...@domenicdenicola.com wrote:
For the record, here's the idea Yehuda and I worked out:
https://gist.github.com
For the record, here's the idea Yehuda and I worked out:
https://gist.github.com/1ab3f0daa7b37859ce43
I would *really* appreciate if people read it (it's easy reading, I promise!)
and incorporated some of our concerns and ideas into their thinking on module
syntax.
In general, it tries to
Readability or library preference aside, I still think it's bizarre that
map.set(key, val)
is analogous to
(dict[key] = val, dict)
and not to
dict[key] = val
When I'm using a fluent library like jQuery or a configuration DSL like those
in the npm packages surveyed, I can see the attraction
+1 (to all sentiments in the message :)
From: Nathan Wallmailto:nathan.w...@live.com
Sent: 12/3/2012 17:53
To: Andrea Giammarchimailto:andrea.giammar...@gmail.com; Rick
Waldronmailto:waldron.r...@gmail.com
Cc: es-discuss@mozilla.orgmailto:es-discuss@mozilla.org
On the subject of ugly code, I believe the killing of @names and the
reintroduction of computed properties means that the typical iterator form will
be something like:
let iterable = { *[iterator]() { yield 5; } };
Presented without comment...
From: Brandon
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org]
On Behalf Of Allen Wirfs-Brock
Sent: Friday, November 30, 2012 19:18
1) Object.getOwnPropertyNames and Object.keys remain unchanged. They only
return a string property key values.
2)
Using https://github.com/substack/defined you can do
var d = require(defined);
var x = d(m.get(key), defaultValue);
Not sure if this is an argument for adding default value because this module is
so ridiculous ... or against it since it’s so trivial to get the functionality
yourself.
From:
For URLQuery in particular, since it's a String-String map, why not just use a
plain-old-JavaScript-object with appropriate interceptions via a proxy? This
provides a much more idiomatic API:
new URLQuery(object) stays the same
urlQuery.get(name) - urlQuery[name][0]
urlQuery.getAll(name) -
Personally, the fact that modules opt in to strict mode completely obviates the
problem for me. I anticipate this to be the case for most non-beginner ES
programmers as well, since they are largely using either a CommonJS-like or an
AMD module system, and as part of an ES6 migration would then
Why go purposefully against the existing terminology of the JavaScript
ecosystem? Just say “deferred” where you have “promise” and “promise” where you
have “future” and you avoid needless confusion and conflict.
This isn’t Scala; we have existing terminology for exactly these concepts. Just
From: Kevin Smith [khs4...@gmail.com]
Sent: Wednesday, November 14, 2012 11:41
Why go purposefully against the existing terminology of the JavaScript
ecosystem? Just say “deferred” where you have “promise” and “promise” where
you have “future” and you avoid needless confusion and conflict.
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Mark S. Miller
Sent: Friday, November 9, 2012 08:33
Hi David, thanks for your thoughtful post. I've always used the two-arg form
of .then[1], but your post makes a strong case for more often using
The recent promise discussion prompted me to recall the following
musing/proposal from Kris Kowal:
https://github.com/kriskowal/q/wiki/On-Exceptions
In short, there's a common code pattern that you can do with promises that you
can't do with synchronous code. The proposal is for a language
The idea is to not do the processing if the JSON parsing fails.
From: Cryptic Swarm [mailto:crypticsw...@gmail.com]
Sent: Friday, November 9, 2012 11:55
To: Domenic Denicola
Cc: es-discuss@mozilla.org
Subject: Re: then
The following should work? Finally expects a block statement, so need to wrap
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Kevin Smith
Sent: Wednesday, November 7, 2012 09:58
The only hard part that isn't really addressed by currently library
implementations is error handling. I feel pretty strongly that rejections
(and
I guess now is a good a time as any to pre-announce Promises/A+:
https://github.com/promises-aplus/promises-spec
It’s an attempt to improve significantly on the minimal-but-perhaps-too-minimal
Promises/A of CommonJS, making the language more rigorous and speccing several
important things
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Mikeal Rogers [mikeal.rog...@gmail.com]
Sent: Tuesday, November 06, 2012 15:33
also, node.js won't adopt either a promise API or a promise syntax for it's
core API. if it lands in the language then nothing is
As an interesting aside, I just wanted to highlight the section of Promises/A+
that Rick was referring to, because I think it uses a rather clever trick to
avoid discussing the event loop while still requiring the behavior we want:
onFulfilled and onRejected must not be called before then
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Axel Rauschmayer
Sent: Tuesday, November 6, 2012 19:07
Different issue: do we already have a solution for a missing error handler
causing silent failures? task.js should cover
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Erik Arvidsson
Sent: Friday, November 2, 2012 13:21
If we call it has, should we also rename String.prototype.contains?
I'd say no; the distinction between collections having an
I do think that including this as a debugging tool is where the most value is.
Whether through an engine-provided API (like V8's gc()/--expose-gc) or through
something more standardized, like the existing `debugger` statement, is the
real question.
On Oct 25, 2012, at 21:04, Alex Russell
On Oct 25, 2012, at 23:13, Andrew Paprocki and...@ishiboo.com wrote:
On Thu, Oct 25, 2012 at 10:14 PM, Shawn Steele
shawn.ste...@microsoft.com wrote:
On the contrary, TypeError: Cannot read property 'prop' of undefined,
with a stack trace, is WAY easier to track down than The RSS on my
Of Domenic Denicola
Sent: Sunday, October 21, 2012 13:46
To: 'es-discuss@mozilla.org'
Subject: Request for feedback on a talk on I'm giving on ES6
(Attempting to send again with fewer URLs to avoid being spam-filtered?
Apologies if this shows up twice.)
On Monday I'll be giving a talk about
On Oct 22, 2012, at 14:28, Yehuda Katz
wyc...@gmail.commailto:wyc...@gmail.com wrote:
On Mon, Oct 22, 2012 at 11:11 AM, Axel Rauschmayer
a...@rauschma.demailto:a...@rauschma.de wrote:
What about copying of these new data structures?
It should be possible to initialize a collection via another
(Attempting to send again with fewer URLs to avoid being spam-filtered?
Apologies if this shows up twice.)
On Monday I'll be giving a talk about ES6 at EmpireJS. I just finished up my
slides, and would love some feedback and critique from the es-discuss crew:
Thanks so much for the feedback!
-Original Message-
From: Brendan Eich [mailto:bren...@mozilla.org]
Sent: Sunday, October 21, 2012 14:17
Slide 15 has a comment at the bottom: // error! used a `let` before
declaration but this error is about the most-indented log call, the one in
Thanks for your help Rick! I've corrected a few, but wasn't sure about some
others. Let me know if I'm missing something in the following:
From: Rick Waldron [mailto:waldron.r...@gmail.com]
Sent: Sunday, October 21, 2012 17:07
nit: The comment itself says // error! used a `let` before
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Kevin Smith [khs4...@gmail.com]
Sent: Friday, October 12, 2012 12:30
Again:
function f(a = 1, b, c) {}
f.length === 0; // Huh?
You seem to be under the mistaken impression that ES6 allows non-defaulted
On Oct 12, 2012, at 13:03, Kevin Smith
khs4...@gmail.commailto:khs4...@gmail.com wrote:
You seem to be under the mistaken impression that ES6 allows non-defaulted
arguments after default ones. This is not the case. See
https://mail.mozilla.org/pipermail/es-discuss/2012-October/025704.html
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Andreas Rossberg
Sent: Friday, October 5, 2012 14:46
On 5 October 2012 14:26, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Fri, Oct 5, 2012 at 8:21 AM, Kevin Smith
Would it suffice to allow cross-frame sharing of symbols via postMessage and
its structured clone algorithm? They're immutable, right?
On Oct 3, 2012, at 15:01, Brendan Eich bren...@mozilla.org wrote:
Thanks for pointing this out. Python's dunder-prefixing or anything like it
in JS has that
From: Rick Waldron [waldron.r...@gmail.com]
Sent: Tuesday, October 02, 2012 16:52
No iteration for spread, per July 24 resolution
https://mail.mozilla.org/pipermail/es-discuss/2012-July/024207.html
Oh, thanks for catching me on that. Silly Firefox...
This seems like an unfortunate decision,
From: Rick Waldron [mailto:waldron.r...@gmail.com]
Sent: Tuesday, October 2, 2012 17:18
On Tue, Oct 2, 2012 at 5:11 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Rick Waldron [waldron.r...@gmail.com]
Sent: Tuesday, October 02, 2012 16:52
No iteration for spread, per
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of David Bruant [bruan...@gmail.com]
Sent: Monday, October 01, 2012 16:23
To: Brendan Eich
Cc: es-discuss
Subject: Re: typeof symbol (Was: Sept 19 TC39 Meeting Notes)
Try typeof
On Oct 1, 2012, at 18:58, Brendan Eich bren...@mozilla.org wrote:
I am warming up to the way CoffeeScript does things -- not the translation
scheme, __extends, __super__ -- rather, the plain Object instance created as
C.prototype that has B.prototype as its [[Prototype]] but has shadowing
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Brendan Eich
Sent: Monday, October 1, 2012 21:43
To: Nicholas C. Zakas
I would really like to see a *Set.prototype.toArray* method to easily
change the Set back into an
On Sep 28, 2012, at 20:58, Brendan Eich bren...@mozilla.org wrote:
John Lenz wrote:
The best thing I see for the future is if the Browser vendors didn't reparse
JavaScript when loading from cache, this would help the best case scenarios,
but doesn't help the worse case where it harder to
As a user, not implementer, I really want early errors. Perf costs of startup
are negligible especially long-term. By the time ES6 is in browsers computers
and phones should be faster by enough of a factor to mitigate any costs,
whereas omitting early errors hurts developers indefinitely into
2. The stated goal of 'let' is to replace 'var' in common usage (and if
this is not the goal, we should not be adding 'let').
There is actually some disagreement about that statement of the goal. The
goal of let is to provide variable that are scoped to the block level. That
is the
On Sep 11, 2012, at 4:39, Brendan Eich bren...@mozilla.com wrote:
Brendan Eich wrote:
Dmitry Soshnikov wrote:
var FOO = 42;
function bar(x, y = FOO + z) { var z = 10; } // Error .. ?
Translating to JS as it is:
var FOO = 42;
function bar(x, y) {
if (y === void 0) y = FOO + z;
For comparison, quite a lot of ECMAScript function names are nouns, e.g.
Date.now, String.prototype.{substring, indexOf}, etc.
From: Norbert Lindenberg
Sent: August 31, 2012 12:16
To: Marcos Caceres
CC: es-discuss
Subject: Re: i18n API - resolvedOptions
Actually, all options have to be
Array.fromElements is solid, especially considering how rarely this will be
used, especially given that it competes in ES6 code with `...x = [...x]`
On Aug 27, 2012, at 23:42, 程劭非 csf...@gmail.com wrote:
Yes, as a developer (but not English native speaker), I really feel
uncomfortable with
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Brendan Eich
Sent: Saturday, August 11, 2012 22:57
As noted, they started out that way 17 years ago. I think WebIDL and
interface-based method definition made onload, e.g.,
Why is there concern about uniqueness at all? Won’t this be inside a module?
import Symbol from @symbols
From: François REMY
Sent: Wednesday, August 1, 2012 17:07:02
To: Rick Waldron, Mark S. Miller
CC: es-discuss
Subject: RE: The Name of the Name
Symbol could already be used by parsers and
On Jun 21, 2012, at 3:22, Herby Vojčík he...@mailbox.sk wrote:
Brendan Eich wrote:
Herby Vojčík wrote:
I feel there is objection to introduce magical [[NullPatternObject]]
into language, but all of CS-style soft-accesses could be solved very
cleanly and consistently.
No, because (a)
501 - 600 of 649 matches
Mail list logo
