ES5's existing array extras make working with arrays a joy.
However, sometimes arrays are not the right tool for the job. Perhaps you want
lazy evaluation semantics (generators). Or perhaps you want to communicate that
the list is immutable (compare .NET's `IEnumerableT` or Java's
, Domenic Denicola
dome...@domenicdenicola.com wrote:
ES5's existing array extras make working with arrays a joy.
However, sometimes arrays are not the right tool for the job. Perhaps you
want lazy evaluation semantics (generators). Or perhaps you want to
communicate that the list is immutable
someVeryLargeArray.iMap(someFunction); // Lazy, guaranteed only to be iterable
How about `someVeryLargeArray.asIterator().map(someFunction)`?
-Domenic
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
This seems like a highly compelling argument. I hope I'm not the only one who
thinks the existing behavior of `for(;;)` makes sense. Granted, that comes from
understanding the detail that closures close over variables and not values,
which most users will not. But in general, `for(;;)` makes it
I am generally with Brendan that specifying __proto__ is not very necessary.
But, one thing I would like enshrined in the spec is that `__proto__ in
Object.create(null) === false`.
___
es-discuss mailing list
es-discuss@mozilla.org
As a starting point, would it make sense to provide an API that matches
Array.prototype methods (where applicable)?
I think this ties in to my earlier desire to make Array.prototype methods work
with iterators in general [1]. That is, I think the correct way to do this
would be:
1) To
Perhaps using indexOfIdentical from
http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Erik Arvidsson [erik.arvids...@gmail.com]
Sent: Thursday, February
I appreciate the feedback, but I do not understand the rationale.
The rationale I found compelling from upthread was that remove is a more apt
antonym to add.
To compare, delete's natural counterpart would be put.
___
es-discuss mailing list
: Tuesday, February 28, 2012 14:38
To: Domenic Denicola
Cc: Allen Wirfs-Brock; Brendan Eich; es-discuss@mozilla.org
Subject: Re: Typeof this in getters (was: eval on non-strings)
I like the output display on http://jsfiddle.net/CxdMs/16/ a bit better. I just
tried it on very recent versions of 4
To clarify, the expected results here are:
Non-strict
Typeof this inside a function when called on a number: object
Typeof this inside an Object.prototype getter when used on a number: object
Strict
Typeof this inside a function when called on a number: number
Typeof this inside an
If we’re taking votes:
-1. I would actively avoid using this in my own ES6 code, because of the
unnecessary confusion it would cause to those coming from CoffeeScript.
From: Carlos Prado García
Sent: Saturday, March 03, 2012 17:58:38
To: es-discuss
Subject: Re: How about replacing | with -
+1
This wins on so many levels:
* Short but C-like myList.map((x) x*x) syntax for the most common cases, where
TCP doesn't matter.
* Full TCP support via an entirely new, but still pretty C-like, syntax with
myList.map((x) do { … }).
* The two are sufficiently close to each other and to the
Just to contribute to this... er... fun-thread...
My team uses the closure pattern for our classes (i.e. no prototype methods
at all), since we value encapsulation. I can't imagine we're alone.
So any class solution that doesn't fully incorporate private names (e.g. by
making them awkward via
, March 16, 2012 17:20
To: Domenic Denicola
Cc: Russell Leggett; Kevin Smith; es-discuss
Subject: usable enough private names (was: Re: Using Object Literals as Classes)
Domenic Denicola wrote:
Just to contribute to this... er... fun-thread...
My team uses the closure pattern for our classes (i.e
On Mar 16, 2012, at 18:05, David Bruant
bruan...@gmail.commailto:bruan...@gmail.com wrote:
Le 16/03/2012 23:00, Rick Waldron a écrit :
On Fri, Mar 16, 2012 at 5:12 PM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote:
Just to contribute to this... er... fun
On Mar 16, 2012, at 18:12, Rick Waldron
waldron.r...@gmail.commailto:waldron.r...@gmail.com wrote:
On Fri, Mar 16, 2012 at 6:04 PM, David Bruant
bruan...@gmail.commailto:bruan...@gmail.com wrote:
Le 16/03/2012 23:00, Rick Waldron a écrit :
On Fri, Mar 16, 2012 at 5:12 PM, Domenic Denicola
From: Rick Waldron [mailto:waldron.r...@gmail.com]
Sent: Friday, March 16, 2012 18:40
To: Domenic Denicola
Cc: David Bruant; es-discuss
Subject: Re: Using Object Literals as Classes
On Fri, Mar 16, 2012 at 6:20 PM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com
From: Axel Rauschmayer [mailto:a...@rauschma.de]
Sent: Friday, March 16, 2012 18:35
To: Domenic Denicola
Cc: Russell Leggett; Kevin Smith; es-discuss
Subject: Re: Using Object Literals as Classes
Just to contribute to this... er... fun-thread...
My team uses the closure pattern for our classes
From: Rick Waldron [mailto:waldron.r...@gmail.com]
Sent: Friday, March 16, 2012 19:28
To: Domenic Denicola
Cc: David Bruant; es-discuss
Subject: Re: Using Object Literals as Classes
On Mar 16, 2012, at 7:11 PM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote
Callable modules are a hugely important use case. jQuery and Underscore spring
to mind. I’ve made one myself [1].
Also important: what about construct-able modules? Or to put it another way,
what about exporting a module that is a class? Examples from Node [2] [3] and
Node-land [4] [5] are
Does passing /foo/i.test not work? (Away from computer.) Perhaps it should, if
it doesn't?
On Mar 23, 2012, at 16:28, Felix Böhm
esdisc...@feedic.commailto:esdisc...@feedic.com wrote:
Hi guys,
just a first try for a proposal: Array.prototype.[filter/some/every] currently
require a function
...@gmail.commailto:russell.legg...@gmail.com wrote:
On Mar 23, 2012, at 9:05 PM, John Tamplin
j...@google.commailto:j...@google.com wrote:
On Fri, Mar 23, 2012 at 8:21 PM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote:
Does passing /foo/i.test not work? (Away from
On Mar 27, 2012, at 13:10, David Herman dher...@mozilla.com wrote:
I recognize the C.prototype.constructor idiom already exists, but it's a weak
idiom. I'm not crazy about the idea of strengthening a problematic but
currently unreliable and rarely used idiom.
Dave
Speaking as a dev, I
Great to gain consensus indeed. This looks just about as nice as it can be.
Minor question: There are no examples of very empty arrow functions, e.g.
`=` or `= 5`. And from what I can tell reading the grammar , they are not
allowed. Is this necessary? CoffeeScript's allowance of `- (expr)`
As a quick follow-up:
Perhaps adding non-arcane-incantation private name declarations would be enough
to push maximally-minimal classes from “nice, but are they worth it?” to “this
gives us something we can’t get anywhere else.” To wit:
class Set extends Collection {
private setContents,
On Apr 7, 2012, at 20:37, Rick Waldron
waldron.r...@gmail.commailto:waldron.r...@gmail.com wrote:
On Sat, Apr 7, 2012 at 8:31 PM, Erik Arvidsson
erik.arvids...@gmail.commailto:erik.arvids...@gmail.com wrote:
On Sat, Apr 7, 2012 at 17:28, Rick Waldron
We use `Function.prototype.partial` in our codebase. We consider
`Function.prototype.papply` but thought that would be too confusing with
`Function.prototype.apply`.
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Axel
The real question is, are there test-262's for this behavior? Or for the
original nonconforming `function true() { }`?
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Mathias Bynens [math...@qiwi.be]
Sent: Thursday,
var tru\u0065; = Expected identifier error in IE9.
console.log(fals\u0065) = Syntax error in IE9.
Can test IE10 when I get home from work.
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Brendan Eich
-boun...@mozilla.org] On
Behalf Of Domenic Denicola
Sent: Thursday, April 12, 2012 13:49
To: Brendan Eich; Allen Wirfs-Brock
Cc: es-discuss Steen
Subject: RE: Fun impossible Firefox JS challenge
var tru\u0065; = Expected identifier error in IE9.
console.log(fals\u0065) = Syntax error in IE9.
Can
I'm sympathetic toward `undefined` as a sentinel for no value of the expected
type, whereas `null` means we have a value of the expected type, but that
value represents 'nothing.' Not sure if anyone else sees it that way, though,
and admittedly it's based on vague hand-wavey arguments.
Tangentially related: https://github.com/kriskowal/q/wiki/On-Exceptions
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Nebojša Ćirić [c...@google.com]
Sent: Tuesday, April 17, 2012 16:39
To: Jussi Kalliokoski
Cc: es-discuss
It seems rather non-intention-revealing.
From: es-discuss-boun...@mozilla.org [es-discuss-boun...@mozilla.org] on behalf
of Mark S. Miller [erig...@google.com]
Sent: Tuesday, April 17, 2012 17:20
To: Brendan Eich
Cc: Tom Van Cutsem; Mark Miller; es-discuss
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Angus Croll
Sent: Saturday, April 21, 2012 16:03
To: Allen Wirfs-Brock
Cc: es-discuss
Subject: Re: A few arrow function specification issues
4) Should it be a dynamic
I'm becoming increasing convinced that the poison pill approach to securing
the caller chain is a poor approach. We keep finding leaks in and it does
nothing to prevent implementation from inventing new ways to expose the
stating they are trying to hide. I now think we would be better off
As a day-to-day user who was not using strict until recently (stubborn other
team member for the loss), I can say that moving to strict was much more a
cleanup experience than a mode experience, with only a few small exceptions:
1) Poison-pilling arguments.callee: some code on the internet
Consider:
try {
doStuff();
} catch (e) {
console.log(uh oh, got an e, e);
throw e;
}
In Node and in all browsers I've tested with, this currently loses the stack
trace for `e`, and more importantly loses debugger step-back-ability in tools
like Firebug and Web Inspector.
One
smaller problem.
From: Rick Waldron [waldron.r...@gmail.com]
Sent: Friday, May 11, 2012 16:10
To: Brendan Eich
Cc: Domenic Denicola; es-discuss@mozilla.org
Subject: Re: Re-throwing errors
On Fri, May 11, 2012 at 2:43 PM, Brendan Eich
bren
I was going over the latest draft and noticed that, while binary and octal
literals have been introduced in 7.8.3, they weren’t added to 9.1.3.1
(“ToNumber applied to the String type”). Should they be?
Pros: symmetry. Cons: breaks backward compatibility (currently
ToNumber(0b1001) returns
The prototyping efforts are appreciated, but can rarely be used in a
comfortable way. (Compared to, say, HTML5.) I've thought a lot about how to
feasibly use Harmony features in real-world code, but have fallen down every
time. Here are some of the stumbling blocks I've encountered:
* Node.js
You are of course right, Brendan, and thanks for addressing my points.
Certainly part of this was fueled more by frustration than informed knowledge
(see below).
-Original Message-
From: Brendan Eich [mailto:bren...@mozilla.com]
The prototyping efforts are appreciated, but can
From: Rick Waldron [mailto:waldron.r...@gmail.com]
Etc. It's ES6-like, but doesn't reflect TC39's actual progress, instead
reflecting the Traceur team's interpretation of where TC39 might eventually,
hopefully, end up.
I don't think this is a fair claim to make, considering Traceur had
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Brendan Eich
Sent: Saturday, May 26, 2012 15:08
New syntax may some day clean all this up but the short path wins and
it'll be hard to displace. Let's be realistic. I agree
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Mark S. Miller
Sent: Thursday, May 31, 2012 22:24
Non-strict mode is so bizzarre that I wouldn't be surprised, but I can't
think of an example. Is my proposed rule unsound
-Original Message-
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-
boun...@mozilla.org] On Behalf Of Allen Wirfs-Brock
Sent: Friday, June 01, 2012 04:05
We haven't eliminated the ability to define object literals that inherit
from objects other than Object.prototype. We
Machine-parsability might be reaching too far, especially if you lose the
benefits of nice function/method name inference. Instead, perhaps a separate
strawman to standardize something like the V8 stack trace API [1]?
It is used in Node for providing long stack traces [2], [3], [4]. It's a bit
In our experience writing large apps, the distinction is useful. Undefined
means I forgot to do something (e.g. set a property or pass an argument); null
means I tried to get something but it didn't exist.
Very roughly, it becomes undefined = caller error outside of my control, null =
my error
On Jun 14, 2012, at 14:03, Rick Waldron
waldron.r...@gmail.commailto:waldron.r...@gmail.com wrote:
On Thu, Jun 14, 2012 at 11:58 AM, Domenic Denicola
dome...@domenicdenicola.commailto:dome...@domenicdenicola.com wrote:
In our experience writing large apps, the distinction is useful. Undefined
What struck me from Jeremy's explanation was the uniformity of CoffeeScript's ?
operator (modulo the small issue he mentioned for function calls). It seems to
combine the currently-strawman'ed ??/??= and ?. into one very simple semantic.
What about adopting ?? as CoffeeScript's ? operator?
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)
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
-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.,
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
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
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;
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
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
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
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
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
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
-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
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
(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
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
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
-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 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
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
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
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.
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
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) -
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:
-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)
+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
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
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
-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
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
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 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
-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
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
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
1 - 100 of 649 matches
Mail list logo
