Note that `Array.from(str)` and `str[Symbol.iterator]` overlap
significantly. In particular, it's somewhat awkward to iterate over
code points using `String#symbolAt`; it's much easier to use
`substr()` and then use the StringIterator.
--scott
ps. I see that Domenic has said something similar.
Yes, I know what `String#at` is supposed to do.
I was pointing out that `String#at` makes it easy to do the wrong
thing. If you do `Array.from(str)` then you suddenly have a complete
random-access data structure where you can find out the number of code
points in the String, iterate it in
Can someone point me to the spec for `System.import`?
https://github.com/jorendorff/js-loaders/blob/master/browser-loader.js
doesn't seem to include it.
It seems to me that it would be worthwhile to ensure that
`System.import` had good semantics. It would allow a nice migration
path for
Thanks. I was missing the relationship between System and Loader somehow.
So System.import is intended to be exactly the same as the import keyword
(except promise-returning). That's good! Is there a way to do without the
export keyword as well (I've heard rumors of anonymous exports but
haven't
I'm excited to start working on es7-shim once we get to that point!
(String.prototype.at has a particularly simple shim, thankfully...)
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
for compatibility if this were transparent in general.)
john: yes, I suspected that System was underspecified. That's too bad.
--scott
On Fri, Feb 14, 2014 at 9:57 AM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
On Fri Feb 14 2014 at 2:20:07 PM, C. Scott Ananian ecmascr...@cscott.net
wrote
yes, of course. es6-shim is a large-ish collection of such.
However, it would be much better to use an implementation of
`String#at` which used substr and thus avoided creating and appending
a new string object.
--scott
___
es-discuss mailing list
For reference: https://bugs.ecmascript.org/show_bug.cgi?id=2546
`Array#copyWithin` has a (non-normative) signature of `(target, start,
end = this.length)`. However, this is slightly misleading because the
spec actually calls `ToLength` on `this.length` and then uses *that*
for the default value
On Fri, Feb 14, 2014 at 11:50 AM, André Bargull andre.barg...@udo.edu wrote:
I think Scott is requesting this change:
https://gist.github.com/anba/6c75c34c72d4ffaa8de7
Yes, although my proposed diff (in the linked bug) was the shorter,
12. If end is undefined, let relativeEnd be
On Fri, Feb 14, 2014 at 6:21 AM, Anne van Kesteren ann...@annevk.nl wrote:
To be clear, we fixed this. And we will be going ahead and shipping
promises in Firefox 29. Too many dependencies at this point to hold of
longer.
Since both Chrome and FIrefox have plans to support Promises, feel
free
On Fri, Feb 14, 2014 at 12:59 PM, David Herman dher...@mozilla.com wrote:
https://github.com/rwaldron/tc39-notes/blob/9ac398908394f9e2f8a1ac9b1e0c83952cd2f2fa/es6/2014-01/jan-28.md#spec-status-update
Yeah, I read that, and I thought the absence of a 'Resolution' was a
bit suspicious. I thought
On Feb 15, 2014 9:13 AM, Brendan Eich bren...@mozilla.com wrote:
Aside: ECMASpeak is neither accurate (we don't work for Ecma, it's JS
not ES :-P), nor euphonious.
I'm learning all sorts of things! I guess there are two names here; what's
your preferred phrase for the language used to write
On Fri, Feb 14, 2014 at 12:40 PM, C. Scott Ananian
ecmascr...@cscott.net wrote:
On Fri, Feb 14, 2014 at 11:50 AM, André Bargull andre.barg...@udo.edu wrote:
I think Scott is requesting this change:
https://gist.github.com/anba/6c75c34c72d4ffaa8de7
Yes, although my proposed diff (in the linked
On Sat, Feb 15, 2014 at 3:17 AM, Anne van Kesteren ann...@annevk.nl wrote:
It will take a long time before browsers support subclassing in
general as far as I can tell.
I'm not talking about the class system in general. I'm talking about
the ES5+ code:
```js
Promise.prototype.bind =
On Mon, Feb 17, 2014 at 7:08 AM, Claude Pache claude.pa...@gmail.com wrote:
Just a last note. Beyond the philosophical aspect whether arraylikes of
negative length make any sense at all, there is a strong technical issue you
have probably overlooked: For array methods in general, and for the
Are recordings available?
--scott
On Feb 17, 2014 10:26 AM, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
On 15 February 2014 20:47, Brendan Eichbren...@mozilla.com wrote:
Using -Speak as a stem conjures Orwell. Not good.
Ah, relax. Gilad Bracha even named his own
It's not the same effect, because `lenVal` could be an object with
valueOf/toString/@toPrimitive side-effects.
Point taken. (Although I'm fine with invoking the side effects twice
if you're using `this.length` as a default value, since that would be
'unsurprising' if you are looking at the
It is straightforward to implement a hash function based map as a
subclass of `Map`. Something like:
```js
var HashMap = function() { this._map = new Map(); };
HashMap.set = function(key, value) {
var hash = key.hashCode();
var list = this._map.get(hash);
if (!list) { list = [];
I like this refactoring. This doesn't change the spec's behavior;
this would be the first solution proposed in
https://bugs.ecmascript.org/show_bug.cgi?id=2546 which was to rewrite
the spec's non-normative text to make it clear that `end=this.length`
in the signature was describing the behavior
[resending to list, original was sent from wrong address and got bounced]
On Tue, Feb 18, 2014 at 11:12 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
On Feb 18, 2014, at 12:44 PM, C. Scott Ananian wrote:
```js
var SubPromise = function(exec) { Promise.call(this, exec
In the ES6 world, you should probably set up a Map for your switch
statement; that would allow you to easily use non-string cases.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
There are a number of differences between ES5-style methods and ES6
methods. This is unfortunate, but probably inevitable.
* ES5 methods typically use argument is present, while ES6 methods
treat an undefined argument as the same as a missing argument. For
example, compare Array#reduce to
On Fri, Feb 21, 2014 at 9:49 AM, Brendan Eich bren...@mozilla.com wrote:
Whatever we do, we should be consistent among sparse arrays and sparse
arraylikes, it seems to me. Want a bug?
Filed https://bugs.ecmascript.org/show_bug.cgi?id=2562
--scott
___
I wasn't confused by the spec text as is, but I'm not surprised that
others are. The language is battling against two different standards
for optional arguments. In ES5 typically not present is used; in ES6
for consistency with the new language optional arguments, undefined
is treated as not
I actually just responded in more depth over at
http://esdiscuss.org/topic/what-does-is-not-present-mean-in-spec-algorithms#content-9
Let's continue the discussion over there.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
On Mon, Feb 24, 2014 at 4:24 PM, Claude Pache claude.pa...@gmail.com wrote:
Indeed, but the question was about producing/forwarding holes rather than
skip them, so that, e.g., `Array.from` could replace the elements at the
correct positions.
You'd probably want `Array.fromEntries` then, and
While we're on the topic, let me bang the drum one last time for tweaking
some of the `Array` built-ins so that they can be applied to `TypedArray`s.
The fact that there are separate `Array.from` and `%TypedArray%.from`
methods in the spec (for example) makes me sad. IIRC all that is needed in
On Tue, Mar 4, 2014 at 12:23 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
There's actually a big difference between %TypedArray%.from and Array.from.
The typed array version must accurately determine the number of elements in
the new array be instantiating it. The regular array can
If you use a getOwnPropertyNames trap, then you also need a
getOwnPropertySymbols trap to implement getOwnPropertyDescriptors.
--scott
On Thu, Mar 6, 2014 at 2:16 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
2014-03-05 20:11 GMT+01:00 C. Scott Ananian ecmascr...@cscott.net:
On Wed, Mar 5
On Thu, Mar 6, 2014 at 6:31 PM, André Bargull andre.barg...@udo.edu wrote:
On 3/6/2014 11:35 PM, Andrea Giammarchi wrote:
The proposed [[GetOwnPropertyNames]] internal method is supposed to be a
more restrictive version of [[OwnPropertyKeys]] to ensure Proxy objects
don't lie about their
How about:
```js
cs = require('coffee-script').compile;
eval(cs`
gcd = (x,y) - [x,y] = [y,x%y] until y is 0; x
`);
```
Presumably coffee-script counts as a (large!) DSL.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
I was also a bit puzzled by the iterator return value. I expected
that it would handle mutation (adding new properties) during traveral
the way that the `Map` and `Set` iterators do. I was surprised to see
that all the users turned the iterator into an array; none seemed to
handle concurrent
Sigh. The example just better demonstrates how clunky the syntax is
and how surprising the semantics can be. :(
rant
I hope one of the CommonJS or RequireJS folks write a good ES6 module
loader so that I can continue to use reasonable syntax and ignore all
of this.
This really smells like
On Fri, Mar 14, 2014 at 3:34 PM, John Barton johnjbar...@google.com wrote:
On Fri, Mar 14, 2014 at 11:42 AM, David Herman dher...@mozilla.com wrote:
When you export from a module, you're exporting bindings, rather than
values. This means you can refactor between
module m from foo;
On Sat, Mar 15, 2014 at 6:19 PM, David Bruant bruan...@gmail.com wrote:
Le 15/03/2014 22:51, C. Scott Ananian a écrit :
It would be nicer to add an Object.entries() method that would return that
iterator.
Object.prototype.entries or Object.entries(obj)?
`Object.entries(obj
We briefly mentioned `Object.entries`/`Object.values` the other day on
list (to complement `Object.keys`).
Is there any concrete plan to propose these for ES6/ES7? Would filing
a bug help? Or maybe just mentioning @rwaldron is enough to magically
make it appear on an agenda. ;)
--scott
On Fri, Mar 21, 2014 at 10:10 AM, Jason Orendorff
jason.orendo...@gmail.com wrote:
Because of that, and because Object.keys already returns an array, I
think Object.values and Object.entries should too.
I agree. This is also consistent with the arrays returned by
getPropertyDescriptors and the
Thanks for the back-reference, Kris. So, everyone seemed to be in
favor of this, it just never got formally added.
@rwaldron, are you interested in championing this for ES7 as well?
--scott
On Fri, Mar 21, 2014 at 12:09 PM, Kris Kowal kris.ko...@cixar.com wrote:
Continuing a 2 year old
Sorry for the confusion. I was actually referring to
[[OwnPropertyKeys]] returning an Array, as discussed previously:
http://esdiscuss.org/topic/object-getownpropertydescriptors-o-plural#content-34
Presumably the corresponding proxy trap would change to return an Array as well.
But this is a
Commenting on this same region:
```
print(points[0].x); // 0 to start
points[0].x = 1;
print(points[0].x); // still 0
points[0] = {x: 1, y: 2};
print(points[0].x); // now 1
```
There's no reason why we couldn't extend the grammar to handle this
case, in the same way that `a.f()` has different
On Thu, Apr 3, 2014 at 3:00 AM, Dmitry Lomov dslo...@chromium.org wrote:
On Thu, Apr 3, 2014 at 8:26 AM, Andreas Rossberg rossb...@google.com
wrote:
A uvalue is deeply uvalue only when its prototype and all the methods
found
there are uvalues. Although this is the case for E, the
On Thu, Apr 3, 2014 at 9:09 AM, Andreas Rossberg rossb...@google.com wrote:
On 3 April 2014 14:57, C. Scott Ananian ecmascr...@cscott.net wrote:
Unfortunately, that only works for primitives because the respective
constructor/wrapper class is known to exist in all realms, it is known
It would be worthwhile to state that iterators returned by 'built-in'
functions always have the no zombies property (once done, stays
done), even though that can't be enforced on user-supplied iterators.
Be generous in what you accept, rigorous in what you emit.
--scott
On Mon, Apr 7, 2014 at
On Fri, Apr 11, 2014 at 1:53 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Fri, Apr 11, 2014 at 5:39 AM, Егор Николаев termi1...@gmail.com wrote:
Long story short:
```javascript
function test( a = 1, b = 2, ...rest, c = 4, d = 5) { console.log(a, b,
rest, c, d) }
test();
+1 from me. I thought through the issue and your proposal seems to make
sense.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I like the `@@return` proposal, and I would like to eventually use `yield`
inside try/finally (with something like `Promise.async` to implement the
poor man's pre-ES7 `await`/`async`), and *yet*:
I support banning `yield` inside try/finally for ES6. That seems the
smallest possible fix for the
On Fri, Apr 25, 2014 at 3:12 PM, Mark S. Miller erig...@google.com wrote:
I would really like to believe that this is adequate to postpone the rest
of this issue to ES7. But even without finally, this proposal would put the
generator in a non-resumable state in ES7 after ES6 would ship them in
Ah. I'm still looking for a minimal safe cut for ES6 -- would it be
possible to remove `@@iterator` from iterators created from generators?
(Now I see that this conversation has turned on itself, since it began
with a discussion about whether iterators should be iterable, etc.)
Again, I would
On Fri, Apr 25, 2014 at 4:15 PM, C. Scott Ananian ecmascr...@cscott.netwrote:
Ah. I'm still looking for a minimal safe cut for ES6 -- would it be
possible to remove `@@iterator` from iterators created from generators?
Nevermind, I realize this doesn't prevent you from storing away
+1 from me as well. None of the proposed quick workarounds are truly safe,
we might as well fix it properly.
--scott
ps. it seems like modules are still the long pole in the tent, so there's a
little bit of time to spend on this?
___
es-discuss
Certainly we could make `.return` always return `undefined` with no loss of
functionality, since the intended use case is simply to trigger `finally`
clauses and close the generator.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
I'm sympathetic to the simplicity argument that says that `.throw` is the
proper way in JS to clean up an iterator. The `.return` proposal seems
like a kludge to work around the fact that ES6 still doesn't have a
discriminatory `catch` clause that can avoid catching the thrown cleanup
exception.
Domenic: the argument against is that changing the semantics of `for of` --
and all of the standard library methods, in the case of exceptional exit --
would result in a user-visible change to the state of the iterator. That
is, the iterator would not be closed, whereas ES6 as it stands now would
On Tue, Apr 29, 2014 at 7:47 PM, David Herman dher...@mozilla.com wrote:
Promised you a reply to this one, sorry -- I'm not comfortable with this
restriction. It violates my Schemer's intuition [1]. In particular it
creates a number of refactoring hazards: (1) add some try/finally
[...]
[1]
On Wed, May 14, 2014 at 9:12 PM, Axel Rauschmayer a...@rauschma.de wrote:
It'd be great if there was material on the limits of the JVM and the CLR.
AFAICT these are the only virtual machines that are trying to be universal
(run both static and dynamic languages well).
Well, from experience,
and what about
obj []= 'propertyName'
as well?
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Fri, May 16, 2014 at 12:49 PM, Mameri, Fred (HBO) fred.mam...@hbo.comwrote:
maintaining performance and debuggability would be nice. But for me, the
main benefit of the bytecode is having my engineering team be able to adopt
newer versions of the language at our convenience (instead of
On Wed, May 21, 2014 at 9:59 AM, Dmitry Lomov dslo...@chromium.org wrote:
I think it would be weird if some of them fail hard and some would behave
as if the length is zero. Consistency is always good.
Why fail hard is more desirable?
It is desirable because it allows for more efficient
I've written a lot of coffeescript code and the existential operator is
indeed one of the joys of the language. I like David's attempt to bring
rigor and compositionality to it.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
, 2014 9:56 PM, Claude Pache claude.pa...@gmail.com wrote:
Le 23 mai 2014 à 03:04, Brendan Eich bren...@mozilla.org a écrit :
C. Scott Ananian wrote:
I've written a lot of coffeescript code and the existential operator is
indeed one of the joys of the language. I like David's
You
I like the idea, but I agree that the .{ } syntax isn't quite right. For
one thing, on my screen the () are visually very similar to {}, while []
are easily distinguished. The leading dot is also a bit odd. I'd be
interested in seeing some more alternative syntaxes for this idea.
--scott
On
So... Safari 8's betas were just released. It contains a partial ES6
implementation -- but one which fails many of `es6-shim`s test cases. See
https://github.com/paulmillr/es6-shim/issues/252#issuecomment-45141791
Is anyone on es6-discuss in contact with the Safari team? Can we get
Safari 8
On Thu, Jun 5, 2014 at 7:15 PM, Axel Rauschmayer a...@rauschma.de wrote:
```js
// Compact ECMAScript 6 solution
// Risk: number overflow
[1, 5, 3, 12, 2].sort((a,b) = a-b)
```
Is this really an issue for IEEE floating point?
--scott
___
es-discuss
On Fri, Jun 6, 2014 at 7:57 AM, Andy Wingo wi...@igalia.com wrote:
Comprehensions match ES6 very well as it is, without considering the
possible addition of parallelism. They even match up well if we add the
other dimension of asynchronous comprehensions -- i.e. [for x of await y
z], (for x
On Tue, Jun 10, 2014 at 2:47 PM, Frankie Bagnardi f.bagna...@gmail.com wrote:
I'd like Object.merge(source, dest), and Object.clone(source).
`Object.assign` is already in the ES6 spec.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
On Wed, Jun 11, 2014 at 11:05 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 6/11/14, 10:58 AM, Rick Waldron wrote:
function isConstructor(C) {
try {
new C();
This will fail for constructors that require actual arguments, right?
For example, this will fail if C === window.Worker in
On Wed, Jun 11, 2014 at 12:44 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Array.from and Array.of have a non-throwing IsConstrutor test because they
are designed to allow things like this:
let of = Array.of;
of(1,2,3,4,5); //Equivalent to: Array.of(1,2,3,4,5)
I don't recall why we
Saving 12 bytes does not seem like an obvious end-programmer benefit
to me. It seems like unnecessary and premature optimization.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Wed, Jun 11, 2014 at 3:27 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Of course this can all be fixed with .bind() or a bind operator, but it
just seems unfortunate to throw out something that's not harming the spec in
favor something that might be problematic in end user
On Wed, Jun 11, 2014 at 3:41 PM, Kevin Smith zenpars...@gmail.com wrote:
Well, you're assuming exactly the state of affairs that this thread is
questioning... The fact that the threat of changing things to this degree
has dredged up such polarized opinions should indicate that we ought to be
It would be slightly more JavaScripty to have
Date.prototype.[[DateValue]] exist, and be set to the epoch or some
such.
This problem actually seems to be an artifact of the way that
[[Construct]] works in ES6 -- but the takeaway is that prototypes of a
class are not themselves instances of the
On Thu, Jun 12, 2014 at 11:42 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
TC39 explicitly agreed that we would move away from the a prototype is an
instance of its constructor model, except where there was known legacy usage
that we had to support. That previous model make it very
FWIW, in Chrome 36:
```javascript
Date.prototype.toString()
Invalid Date
({ toString: Date.prototype.toString }).toString()
TypeError: this is not a Date object.
Number.prototype.toString()
0
String.prototype.toString()
Boolean.prototype.toString()
false
RegExp.prototype.toString()
/(?:)/
On Thu, Jun 12, 2014 at 12:48 PM, Jason Orendorff
jorendo...@mozilla.com wrote:
In any case, I doubt we have a choice. ES3-5 at least supported it. There is
surely a Web page somewhere that calls .toString() on every object it can
find, just because.
If you are concerned about compatibility,
On Thu, Jun 12, 2014 at 12:59 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
So, I think the current spec. best matches our consensus about changing
these prototypes to non-consructor instances. I think my proposed
alternative toString fall back pattern is more useful, but is a bigger
On Thu, Jun 12, 2014 at 2:30 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
I *really* wish we just had an @@new for this, such that
new C(...args)
is just shorthand for
C[Symbol.new](...args)
and the construct trap could be removed from proxies altogether. :-|
+1.
On Thu, Jun 12, 2014 at 3:06 PM, Till Schneidereit
t...@tillschneidereit.net wrote:
On Thu, Jun 12, 2014 at 8:29 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
(a) `#toString` throws TypeError when given a non-instance. Changes
`Date#toString()`, no change to `Date#toString.call({})`.
(b
On Thu, Jun 12, 2014 at 3:56 PM, Mark S. Miller erig...@google.com wrote:
I like this list. I prefer #c.
* We have previously succeeded at making previously non-generic methods
generic. I think we could get away with #c.
* It is easier for a normal JS programmer to do the equivalent of #c for
On Thu, Jun 12, 2014 at 3:21 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
It's not obvious to me why we would need @@new in addition to @@create (which
is pretty much equivalent to saying it's not clear to me why we need
[[Construct]]). For the ordinary case, @@new would just be another
On Fri, Jun 13, 2014 at 6:33 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
Jason proposes:
new C(...args) = C[Symbol.new](...args)
Allen proposes:
new C(...args) = C.apply(C[Symbol.create](), args)
Consider also the way the spec could read. For example, for the
'Error' object,
On Thu, Jun 12, 2014 at 11:11 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
I guess part of it is clarifying which part of script's insane parsing
rules we're talking about. From what I'm aware of there are quite a lot of
different insanities; but I am fuzzy on the details. Does
On Fri, Jun 13, 2014 at 12:15 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
- Does not require escaping' in any contexts.
`` will need to be escaped if it would otherwise start `/module`, of
course. But I'm pretty sure you mean, does no character reference
processing.
-
On Fri, Jun 13, 2014 at 12:57 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Fri, Jun 13, 2014 at 12:53 PM, Anne van Kesteren ann...@annevk.nl
wrote:
On Fri, Jun 13, 2014 at 6:45 PM, Mark S. Miller erig...@google.com
wrote:
Hi Anne, I didn't understand the answer. When an old browser that
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 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
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
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 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
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
On Tue, Jun 17, 2014 at 11:33 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
I'm not sure who introduced the idea that the Date.prototype should have a
zero value, but that is inconsistent with ES35 where the TimeValue of
Date.prototype is NaN:
+1.
I think you could also remove the 'construct' handler in Proxy
(http://people.mozilla.org/~jorendorff/es6-draft.html#sec-construct-internal-method
step 4), as the @@new method can be handled with the usual proxy
method dispatch mechanism. I'll leave it to someone who better
understands
My guess would be that `catch` is reserved so that (in a future
version of JavaScript) this won't be ambiguous:
```
try { stuff(); }
catch(e1) { }
catch(e2) { }
```
Currently JS only allows a single catch clause. But if it ever grows
guarded catch expressions, then you would want to add multiple
On Wed, Jun 18, 2014 at 2:18 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
I had a syntactic restriction on `super` for two reasons, neither one
related to the kind of invariant you're thinking of: (1) if the
super() call isn't there, I wanted to call it implicitly, for
convenience and
On Wed, Jun 18, 2014 at 3:08 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
I think that fact that these really are semantically equivalent:
function F(x) {this.foo=x};
class F {constructor(x) {this.foo=x}};
is pretty important to the evolutionary nature ES6 classes.
That's the easy
While we're on the topic, shall we discuss `valueOf()`? Should it get the
same treatment?
--scott
On Jun 19, 2014 1:28 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Jun 19, 2014, at 3:18 AM, Till Schneidereit wrote:
On Thu, Jun 19, 2014 at 1:39 AM, Allen Wirfs-Brock
But why? The benefit of named exports in general is that you get the magic
mutable bindings -- but underscore and glob are mature libraries without
circular dependencies on other code. They would gain exactly nothing from
switching to named exports.
--scott
On Jun 19, 2014 4:16 PM, Domenic
On Jun 20, 2014 11:39 AM, John Barton johnjbar...@google.com wrote:
I started out with a similar opinion. Then I wrote some ES6 code.
What we need now is experience from using ES6-modules. We have plenty
of decent implementations. We've built nodejs and browser applications
based on ES6
I am ambivalent about where it goes; it depends to some degree with
how the feature is implemented.
`setTimeout(function() { throw e; }, 0);` is ugly, but it seems to
have most of the behavior you want. There are similar mechanisms with
promises and jobs that could be used. I believe Allan said
On Tue, Jun 24, 2014 at 9:26 AM, Kevin Smith zenpars...@gmail.com wrote:
Ron Buckton's suggestion above makes the most sense to me personally. And
I saw many people arrive to a very similar idea a few times in these
recent
module threads - but it kind of always gets rejected with no substantial
On Tue, Jun 24, 2014 at 10:05 AM, Kevin Smith zenpars...@gmail.com wrote:
Lots of things are breaking API changes. Changing the name of one of the
named exports, for instance. Critically, in Ron's proposal, you *can*
change a default export to named exports later (or vice versa) *without
1 - 100 of 244 matches
Mail list logo
