An alternate way of integrating integers
I’ve written a proposal that sketches an alternative to Dan’s proposal. It has different pos and cons, so it’s mainly about exploring if there are other options. https://gist.github.com/rauschma/13d48d1c49615ce2396ce7c9e45d4cd1 -- Dr. Axel Rauschmayer a...@rauschma.de dr-axel.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How about awaiting Arrays ?
I like the following way of using `Promise.all()`:
```js
const all = Promise.all.bind(Promise);
const allTheThings = await all([pa, pb, pc]);
```
> On 3 Mar 2017, at 13:43, Andrea Giammarchi <andrea.giammar...@gmail.com>
> wrote:
>
> Not the first time I accidentally type the following:
>
> ```js
> const allTheThings = await [pa, pb, pc];
> ```
>
> I am assuming that JS will implicitly realize that'd be a `Promise.all([pa,
> pb, pc])` call but nope.
>
> Then I also realize it'd be cool to have other shortcuts too that play nice
> with arrays such:
>
> ```js
> Array.prototype.all = function all() { return Promise.all(this); };
> Array.prototype.race = function race() { return Promise.race(this); };
>
> // with the lovely addiction of ...
> Array.prototype.any = function any() { return Promise.any(this); };
>
> // with Promise.any being (sorry it was a tweet)
> Promise.any = $ => new Promise((D,E,A,L) => {
> z = [];
> _ = $.map(($, i) => Promise.resolve($)
> .then(D, O => { z[i] = O; --_ || E(z) })
> ).length
> });
> ```
>
> So that ...
> ```js
> const allTheThings = await [pa, pb, pc].all();
> ```
>
> Yay? Nay? Silly? no-way?
>
> I thought it was worth it to point this out.
>
> Best Regards
>
> _______
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
--
Dr. Axel Rauschmayer
a...@rauschma.de
dr-axel.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Do we really need async generators?
I’ve thought some more about the async iteration proposal [1] and my thinking has evolved: * I find the async iteration protocol and `for-await-of` useful. * But I still suspect that Communicating Sequential Processes (i.e., async functions plus library code) are a simpler solution than async generators. I’m genuinely interested in finding the best possible approach, so any kind of feedback is welcome – especially if CSP have any kind of deficiency that I have overlooked. Details: https://gist.github.com/rauschma/4dc86ea81585fcfe056de3caa19aa38f <https://gist.github.com/rauschma/4dc86ea81585fcfe056de3caa19aa38f> (I’ll probably publish this blog post on Monday or Tuesday) [1] https://github.com/tc39/proposal-async-iteration Axel -- Dr. Axel Rauschmayer a...@rauschma.de dr-axel.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: SharedArrayBuffer: cloning vs transferring?
Thanks! This worked for me for a toy example (for multiple calls, I’d record
whether an exception was thrown during the first try):
```
try {
// Try new API (clone)
worker.postMessage({sharedBuffer});
} catch (e) {
// Fall back to old API (transfer)
worker.postMessage({sharedBuffer}, [sharedBuffer]);
}
```
Complete source code:
https://github.com/rauschma/shared-array-buffer-demo/blob/master/main.js
Axel
> On 25 Jan 2017, at 15:03, Lars Hansen <lhan...@mozilla.com> wrote:
>
> You're asking about how postMessage() handles a SharedArrayBuffer, since the
> spec changed last summer from requiring the buffer to be in the transfer list
> to forbidding it. For the time being, Firefox allows the SAB to be in the
> transfer list but prints a warning in the console; by and by we will throw an
> error for that (and until then we'll fail any test cases that test for an
> exception). This is implemented in Firefox 51, if my testing right now is
> correct.
>
> Since no browser has officially shipped this functionality I think some
> browser sniffing may be reasonable for early adopters who want to operate in
> a multi-browser setting. I would expect that when this functionality is
> enabled by default in a browser the browser would adhere to the spec.
>
> --lars
>
>
> On Wed, Jan 25, 2017 at 10:49 AM, Axel Rauschmayer <rausc...@icloud.com
> <mailto:rausc...@icloud.com>> wrote:
> AFAICT, all current implementations want you to transfer SABs. What’s the
> best way to prepare for the future? `try` transferring and clone in the
> `catch` clause?
>
> Thanks!
>
> Axel
>
> --
> Dr. Axel Rauschmayer
> rauschma.de <http://rauschma.de/>
> [Sent from a mobile device, please forgive brevity and typos]
> ___
> es-discuss mailing list
> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss
> <https://mail.mozilla.org/listinfo/es-discuss>
>
--
Dr. Axel Rauschmayer
a...@rauschma.de
dr-axel.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
SharedArrayBuffer: cloning vs transferring?
AFAICT, all current implementations want you to transfer SABs. What’s the best way to prepare for the future? `try` transferring and clone in the `catch` clause? Thanks! Axel -- Dr. Axel Rauschmayer rauschma.de [Sent from a mobile device, please forgive brevity and typos] ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function#toString revision: JSDoc comments?
My initial motivation was to create a Python-style help() function. But I agree that it’s probably better not to depend on this mechanism. > On 16 Apr 2016, at 19:28, Jordan Harband <ljh...@gmail.com> wrote: > > As I see it, the primary purpose of the `Function#toString` proposal is to > document what browsers already do, and tighten it down so they can't deviate > further (which some browsers already have begun to do with "class", for > example). > > "Preceding comments" would be a very hard thing to specify without unduly > blessing an arbitrary documentation pattern, especially one that isn't > universally considered to be a good thing. > > Reflection methods on functions are certainly a potential separate proposal, > if you can make a compelling argument that it's a good idea to reflect on > functions in this manner. > > On Sat, Apr 16, 2016 at 9:42 AM, Marius Gundersen <gunder...@gmail.com > <mailto:gunder...@gmail.com>> wrote: > Would it not be better to expose the names (and default values, > destructurings, etc) of the function arguments using reflection? For example, > Reflection.arguments(Math.max).then this method can return any JSDoc it is > able to parse. > > On 16 Apr 2016 16:53, "Caitlin Potter" <caitpotte...@gmail.com > <mailto:caitpotte...@gmail.com>> wrote: > How would that interact with angular.js' Function.prototype.toString parsing? > Seems like doing that could break some content, even if it were useful > > On Apr 16, 2016, at 10:48 AM, Axel Rauschmayer <rausc...@icloud.com > <mailto:rausc...@icloud.com>> wrote: > >> Regarding this proposal: >> https://github.com/tc39/Function-prototype-toString-revision >> <https://github.com/tc39/Function-prototype-toString-revision> >> >> Wouldn’t it make sense to include a preceding JSDoc-style comment in a >> function’s (or method’s) `[[SourceText]]` value? Conceptually it is a part >> of the function and it could be used to implement a REPL `help()` function. >> >> -- >> Dr. Axel Rauschmayer >> a...@rauschma.de <mailto:a...@rauschma.de> >> rauschma.de <http://rauschma.de/> >> ___ >> es-discuss mailing list >> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> >> https://mail.mozilla.org/listinfo/es-discuss >> <https://mail.mozilla.org/listinfo/es-discuss> > > ___ > es-discuss mailing list > es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> > > > ___ > es-discuss mailing list > es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> > > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function#toString revision: JSDoc comments?
Right. That’s a compelling argument against my suggestion. > On 16 Apr 2016, at 16:53, Caitlin Potter <caitpotte...@gmail.com> wrote: > > How would that interact with angular.js' Function.prototype.toString parsing? > Seems like doing that could break some content, even if it were useful > > On Apr 16, 2016, at 10:48 AM, Axel Rauschmayer <rausc...@icloud.com > <mailto:rausc...@icloud.com>> wrote: > >> Regarding this proposal: >> https://github.com/tc39/Function-prototype-toString-revision >> <https://github.com/tc39/Function-prototype-toString-revision> >> >> Wouldn’t it make sense to include a preceding JSDoc-style comment in a >> function’s (or method’s) `[[SourceText]]` value? Conceptually it is a part >> of the function and it could be used to implement a REPL `help()` function. >> >> -- >> Dr. Axel Rauschmayer >> a...@rauschma.de <mailto:a...@rauschma.de> >> rauschma.de <http://rauschma.de/> >> ___ >> es-discuss mailing list >> es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> >> https://mail.mozilla.org/listinfo/es-discuss >> <https://mail.mozilla.org/listinfo/es-discuss> -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JavaScript Language feature Idea
Another possibility is `Array.prototype.get()`, which would be in line with ES6 Maps. > On 02 Feb 2016, at 21:15, Jonas Sicking <jo...@sicking.cc> wrote: > > On Mon, Jan 25, 2016 at 12:38 PM, Andrea Giammarchi > <andrea.giammar...@gmail.com> wrote: >> FWIW `.at` works for me. Anything really, as long as `Symbol.last` won't >> even be proposed :D > > If we name it `.item` that would mean that a whole bunch of DOM > classes could be replaced with plain JS Arrays. > > For example FileList, MessagePortList, DOMRectList, TouchList, etc. > > It would also mean API compatibility with a whole lot of more APIs, > like NodeList, DOMTokenList and CSSValueList. While we couldn't > replace these with actual Arrays (for varying reasons), we'd end up > with classes that have more API surface in common. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Function#toString revision: JSDoc comments?
Regarding this proposal: https://github.com/tc39/Function-prototype-toString-revision <https://github.com/tc39/Function-prototype-toString-revision> Wouldn’t it make sense to include a preceding JSDoc-style comment in a function’s (or method’s) `[[SourceText]]` value? Conceptually it is a part of the function and it could be used to implement a REPL `help()` function. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Automatically giving symbols descriptions
I love how ES6 automatically gives anonymous function definitions names (via
the variables they are assigned to etc.). Wouldn’t the same make sense for
symbols?
Hypothetical example:
```js
const foo = Symbol();
console.log(Symbol('foo').toString()); // Symbol(foo)
```
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Rename RequireObjectCoercible in some contexts?
I realize that this is nit-picky, but the name `RequireObjectCoercible` feels wrong (and not intention-revealing) in the following context (which is not about objects at all): 1. Let O be ? RequireObjectCoercible(`this` value). 2. Let S be ? ToString(O). Something like `RequireActualValue` or `ThrowIfUndefinedOrNull` seems like a better choice here. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Aren’t membranes incompatible with private data via WeakMaps?
Thanks! I forgot about unwrapping.
> On 22 Nov 2015, at 00:32, Mark S. Miller <erig...@google.com> wrote:
>
> Answering the question in the subject line, no. The key is the difference
> between a standalone proxy and a membrane. With a membrane, the key is that
> the:
>
> * Countdown class
> * Countdown.prototype
> * Countdown.prototype.dec
> * instances of the Countdown class
> * the WeakMaps used by the Countdown class to store it private state
> (_counter, _action)
>
> are all on one side of the membrane. As is conventional, let's call that the
> wet side, and the other side the dry side. Say both a Countdown instance c
> and the WeakMap _action get passed through the membrane. Let's name the
> corresponding dry proxies dry_c and dry_action. If, on the dry side, someone
> does
>
> dry_action.get(dry_c)
>
> then this would trap on dry_action, passing dry_c back through the membrane,
> resulting in the dry_action handler performing, on the wet side
>
> const r = _action.get(c)
>
> The wet result, r, of this invocation would get passed back through the
> membrane, leading to the original expression returning dry_r.
>
> Alternatively, let's say that someone on the dry side does
>
> dry_c.dec()
>
> This traps on dry_c, which looks up c's inherited "dec" method, passes that
> back through the membrane, resulting in a dry_dec proxy for that method. When
> that is invoked with dry_c as its this, it traps, invoking the wet dec method
> with c as its this.
>
> Conclusion: it all works fine.
>
>
> On Sat, Nov 21, 2015 at 3:02 PM, Axel Rauschmayer <rausc...@icloud.com
> <mailto:rausc...@icloud.com>> wrote:
> Take, for example, the following class, which uses WeakMaps for its private
> data:
>
> ```js
> let _counter = new WeakMap();
> let _action = new WeakMap();
> class Countdown {
> constructor(counter, action) {
> _counter.set(this, counter);
> _action.set(this, action);
> }
> dec() {
> let counter = _counter.get(this);
> if (counter < 1) return;
> counter--;
> _counter.set(this, counter);
> if (counter === 0) {
> _action.get(this)();
> }
> }
> }
> ```
>
> If you wrap an instance of `Countdown` with a revocable Proxy (e.g. when it
> is returned by a method inside a membrane) that resets its private state,
> because its `this` changes.
>
> Right? If yes then I’d expect that to cause problems for code that uses
> WeakMaps for private data.
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Is wiki.ecmascript.org down?
I wanted to read the following document, but couldn’t access the server: http://wiki.ecmascript.org/doku.php?id=strawman:proxy_symbol_decoupled <http://wiki.ecmascript.org/doku.php?id=strawman:proxy_symbol_decoupled> Does the server still exist? If not, is the document available somewhere else? Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Aren’t membranes incompatible with private data via WeakMaps?
Take, for example, the following class, which uses WeakMaps for its private
data:
```js
let _counter = new WeakMap();
let _action = new WeakMap();
class Countdown {
constructor(counter, action) {
_counter.set(this, counter);
_action.set(this, action);
}
dec() {
let counter = _counter.get(this);
if (counter < 1) return;
counter--;
_counter.set(this, counter);
if (counter === 0) {
_action.get(this)();
}
}
}
```
If you wrap an instance of `Countdown` with a revocable Proxy (e.g. when it is
returned by a method inside a membrane) that resets its private state, because
its `this` changes.
Right? If yes then I’d expect that to cause problems for code that uses
WeakMaps for private data.
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Decorators for functions
https://github.com/wycats/javascript-decorators/blob/master/README.md The decorator proposal does not include decorators for functions, because it isn’t clear how to make them work in the face of hoisting. However, it would be great to have them. I see two possible solutions: – A decorator on a function declaration prevents hoisting. – Enable decorators for function expressions, arrow functions and generator function expressions. Does either one of those make sense? Axel -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
The name of Array.prototype.includes
There are two existing methods that are loosely similar to `Array.prototype.includes()`: 1. `String.prototype.includes()` 2. `Set.prototype.has()` Isn’t #2 more similar than #1? Shouldn’t the method be called `Array.prototype.has`, then? -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Will FP ever have a great Stack Trace story in JS?
> Not quite, the mechanism which does this in the spec is SetFunctionName
> (http://www.ecma-international.org/ecma-262/6.0/#sec-setfunctionname
> <http://www.ecma-international.org/ecma-262/6.0/#sec-setfunctionname>), and
> it only works for specific syntactic constructs (eg, `foo = function() {}` ->
> anonymous function is named “foo”, let x = () => {} -> anonymous arrow is
> named “x”, etc).
>
> It does not apply to things like `compose(thingA, thingB)`, which is not an
> anonymous function definition.These function names aren’t set at runtime,
> it’s a parse-time operation, and depends on the productions that are parsed.
Ah, fascinating! That’s something that I overlooked. It is an odd mix of static
and dynamic, though.
For example:
http://www.ecma-international.org/ecma-262/6.0/#sec-assignment-operators-runtime-semantics-evaluation
<http://www.ecma-international.org/ecma-262/6.0/#sec-assignment-operators-runtime-semantics-evaluation>
My understanding:
– The actions themselves happen at runtime, not at compile time.
– (1.e) IsAnonymousFunctionDefinition() is a static check that only holds if
AssignmentExpression is an anonymous function expression (syntactically).
– (1.e.i) is a dynamic check, SetFunctionName() happens dynamically, too.
Wouldn’t it make sense to turn IsAnonymousFunctionDefinition() into a dynamic
check, too? A check whether _rval_ is a function should suffice (given the
check whether property `name` exists, later).
--
Dr. Axel Rauschmayer
a...@rauschma.de <mailto:a...@rauschma.de>
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
The name of a method whose key is a symbol
This is the behavior defined in the spec:
```js
const key1 = Symbol('description');
const key2 = Symbol();
let obj = {
[key1]() {},
[key2]() {},
};
console.log(obj[key1].name); // '[description]'
console.log(obj[key2].name); // ''
```
I’m wondering: if a symbol has no description, wouldn’t it be better to give
the method the name `'[]'` instead of the empty string?
--
Dr. Axel Rauschmayer
a...@rauschma.de <mailto:a...@rauschma.de>
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Named Paramters
On 12 Jul 2015, at 16:05, Luke Scott l...@webconnex.com wrote: Personally I'd rather be able to name parameters without creating an object. The intermediate object seem like something that JavaScript engines could eliminate by statically analyzing the code. I’m wondering whether any engine is planning to do that. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Move es-discuss to discuss.webplatform.org?
OTOH I know people (dherman, cough) who can't hack the email load of es-discuss, and do not like the well-known email tendency to have threads run off the rails into endless digression and argumentation. But Arv's point about gmail mute feature is good. I think any competent email reader should have that. My biggest concern is that you can’t be selective in your consumption of es-discuss: It’s all or nothing (even if you only want to participate occasionally). The volume is daunting, esp. with a mobile device. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Move es-discuss to discuss.webplatform.org?
I'm with Scott. Regardless, this conversation is a non-starter. I started it, because I care about es-discuss. More information would be nice as to why it is a non-starter. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Move es-discuss to discuss.webplatform.org?
http://discourse.specifiction.org/t/upcoming-migration/805 http://discourse.specifiction.org/t/upcoming-migration/805 Would it make sense to move es-discuss to that upcoming site? I’m not particularly fond of mailing lists and much prefer forums, especially discourse-based ones. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: revive let blocks
On 18 Jun 2015, at 15:59 , Bradley Meck bradley.m...@gmail.com wrote:
(a=1)={
console.log(a)
}()
Is less verbose than an IIFE and keeps `this` the same. Also keeps the
initialization and init of the variable in the same place.
Neat trick. Caveat – you need parentheses around the arrow function:
```js
((a=1)={
console.log(a)
})();
```
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript 2015 is now an Ecma Standard
The official document is now available from Ecma in HTML at http://www.ecma-international.org/ecma-262/6.0 http://www.ecma-international.org/ecma-262/6.0 and as a PDF at http://www.ecma-international.org/ecma-262/6.0/ECMA-262.pdf http://www.ecma-international.org/ecma-262/6.0/ECMA-262.pdf I recommend that people immediately start using the Ecma HTML version in discussion where they need to link references to sections of the specification. FWIW: I’ve made a list of all IDs from the old ES6 HTML spec [1] that don’t work anymore (spoiler: only a few of the symbolic ones): https://gist.github.com/rauschma/c144d5d58d7afb3d88b8 [1] https://people.mozilla.org/~jorendorff/es6-draft.html -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
PerformPromiseAll
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-performpromiseall https://people.mozilla.org/~jorendorff/es6-draft.html#sec-performpromiseall I’m wondering: Is it OK that PerformPromiseAll invokes `resolve()` via `C.resolve()` (versus `this.resolve()`) with `C` determined via the species pattern? Rationale: `resolve()` uses the species pattern, too (which is why `this.resolve()` works well). Therefore, the species pattern is used twice, which may lead to unexpected effects: You define the species of `this` to be X, but the species of X is Y. Then `Promise.all()` creates an array with instances of Y, not X. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Fixing `Promise.resolve()`
Is there any way to find out how this works *now*? I can’t find the May 2015 meeting notes, either. Do all static Promise methods now just use `this` (e.g. `Promise.all()` → `this.promiseResolve(···)`)? Or only `Promise.resolve()`? Thanks! Axel On 02 Jun 2015, at 23:28, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Jun 2, 2015, at 2:01 PM, Mark S. Miller wrote: Hi Scott, If the change is as simple as it appears, it seems it will go into ES6 itself! The fix has already been made to the production copy that will be released in a couple weeks when we have ECMA GA approval Allen Thanks for pushing this forward. On Tue, Jun 2, 2015 at 1:25 PM, C. Scott Ananian ecmascr...@cscott.net mailto:ecmascr...@cscott.net wrote: Thanks! It looks like core-js has already patched in the new spec: https://github.com/zloirock/core-js/issues/75 https://github.com/zloirock/core-js/issues/75 I've opened https://github.com/paulmillr/es6-shim/issues/344 https://github.com/paulmillr/es6-shim/issues/344 on es6-shim, and I'll see if I can get a patch together for it. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1170742 https://bugzilla.mozilla.org/show_bug.cgi?id=1170742 against Mozilla. I've filed https://code.google.com/p/v8/issues/detail?id=4161 https://code.google.com/p/v8/issues/detail?id=4161 against v8. Allen: Will this be an errata to ES6, part of ES7, or something else? --scott -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
@@isConcatSpreadable
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.concat I’m not seeing @@isConcatSpreadable being used as a property key anywhere in the spec. Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: About generators
Thanks Aaron! The longer version of that blog post is here: http://www.2ality.com/2015/03/es6-generators.html On 14 May 2015, at 08:30, Aaron Powell m...@aaron-powell.com wrote: I’ve done a few blog posts on the topic: http://www.aaron-powell.com/posts/2014-01-13-functions-that-yield-mutliple-times.html http://www.aaron-powell.com/posts/2014-01-13-functions-that-yield-mutliple-times.html http://www.aaron-powell.com/posts/2014-01-18-calling-up-callbacks-with-yield.html http://www.aaron-powell.com/posts/2014-01-18-calling-up-callbacks-with-yield.html http://www.aaron-powell.com/posts/2014-01-28-cleaning-up-promises-wit-yield.html http://www.aaron-powell.com/posts/2014-01-28-cleaning-up-promises-wit-yield.html Axel has blogged about them too - http://www.2ality.com/2013/06/iterators-generators.html http://www.2ality.com/2013/06/iterators-generators.html From: es-discuss [mailto:es-discuss-boun...@mozilla.org mailto:es-discuss-boun...@mozilla.org] On Behalf Of mohan.radhakrish...@cognizant.com mailto:mohan.radhakrish...@cognizant.com Sent: Thursday, 14 May 2015 4:10 PM To: es-discuss@mozilla.org mailto:es-discuss@mozilla.org Subject: About generators Hi, I have used simple generators but there seem to be some advanced usages. I came across these git references from another post and I have looked at the code. What are some articles that explain these concepts for JS developers before delving into this type of code ? Is reading this code the only way ? https://github.com/spion/genny https://github.com/spion/genny https://github.com/creationix/gen-run https://github.com/creationix/gen-run https://github.com/tj/co https://github.com/tj/co https://github.com/jmar777/suspend https://github.com/jmar777/suspend Thanks, Mohan This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law, this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored. ___ es-discuss mailing list es-discuss@mozilla.org mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
13.6.4.12 Runtime Semantics: ForIn/OfHeadEvaluation ( TDZnames, expr, iterationKind, labelSet)
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-forin-div-ofheadevaluation-tdznames-expr-iterationkind-labelset https://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-forin-div-ofheadevaluation-tdznames-expr-iterationkind-labelset I don’t understand step 2: the temporary environment TDZ is created for step 3. All bindings of TDZ are mutable (even the `const`-declared ones). It looks like TDZ is thrown away afterwards. Why is this step necessary? Why are all bindings mutable? Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
extends null
Is this the best way to use `extends null`?
```js
class C extends null {
constructor() {
let _this = Object.create(C.prototype);
return _this;
}
}
```
You can’t use `this`, because it can’t be initialized via a super-constructor
call: the super-constructor is `Function.prototype` (which can’t be
constructor-called).
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Merge map values
The best I can come up with is a totally different, less functional approach:
```js
const s = 'mainn';
let map = new Map();
for (let ch of s) {
ch = ch.toLowerCase();
const prevCount = map.get(ch) || 0;
map.set(ch, prevCount+1);
}
```
On 28 Apr 2015, at 10:52 , mohan.radhakrish...@cognizant.com
mohan.radhakrish...@cognizant.com wrote:
Hi,
I am using ES6 by transpiling. The features remind me of Java lambdas.
If I have a string ‘mainn’ then my map should contain this.
[a=1, i=1, m=1, n=2]
Java : Example. I may not need the TreeMap here.
String s = __mainn__.replaceAll([^a-z\\s], );
final MapCharacter, Integer count = s.chars().
map(Character::toLowerCase).
collect(TreeMap::new, (m, c) - m.merge((char) c, 1, Integer::sum),
Map::putAll);
What could be the es6 equivalent ?
Thanks,
Mohan
This e-mail and any files transmitted with it are for the sole use of the
intended recipient(s) and may contain confidential and privileged
information. If you are not the intended recipient(s), please reply to the
sender and destroy all copies of the original message. Any unauthorized
review, use, disclosure, dissemination, forwarding, printing or copying of
this email, and/or any action taken in reliance on the contents of this
e-mail is strictly prohibited and may be unlawful. Where permitted by
applicable law, this e-mail and other e-mail communications sent to and from
Cognizant e-mail addresses may be monitored.
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
https://mail.mozilla.org/listinfo/es-discuss
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Template strings flags
Alternative: an operator for function composition. ```js let text = `…` @@ t; ``` On 17 Apr 2015, at 19:13, monolithed monolit...@gmail.com wrote: Why not provide special formatting flags for `Template strings`? ```js let text = `text text text text text text text text text text text text`t; ``` `t` - trim whitespaces Expected result: ```js let text = `text text text text text text text text text text text text`t; ``` -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Please volunteer to maintain the HTML version of the spec
I could probably come up with a way to include permanent ids in section headings as Word invisible fields. It would be a little more work for spec. editors (and somewhat bug prone: forgetting to include one, forgetting to change the id when copying a heading, etc) but would eliminate the need to maintain an external map. That is a great idea! It may make sense to make each top-level section a separate namespace then it’s easier to keep IDs unique and there is graceful degradation. One way of achieving that is by breaking up the HTML spec into one page per top-level section, but that has disadvantages, too. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Could we make %ArrayPrototype%'s [[DefineOwnProperty]] throw or no-op for numeric keys?
As long as we have mutable __proto__ in the language that is not going to help. And even then, you'd have to restrict the whole prototype chain, including Object.prototype. AFAICT, the only working solution is to change the behaviour of [[Get]] on arrays, such that they do not consider inherited numeric properties -- like typed arrays, or what we propose for strong mode arrays. Would it help if one introduced new methods `get()` and `set()` for accessing array elements? They could be overridden, but that seems like a simpler, more optimizable check. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array comprehensions with Spread operator
It’s important to keep in mind that there is no official version of array comprehensions, at the moment. So that is something to keep in mind whenever they are added to the language. I’d probably implement flatMap() and use it if I ever needed to do something like this. On 15 Apr 2015, at 18:34, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Apr 15, 2015 at 9:31 AM, Jeremy Martin jmar...@gmail.com wrote: Why not just `[...x, ...y]`? Obviously that's a solution to the trivial example that monolithed provided, but it's not a solution to the more general problem he's alluding to, where you're doing a comprehension and want to insert two or more elements into the result in a single iteration. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array comprehensions with Spread operator
Right, `map()` et al. plus arrow functions come pretty close to the syntactic elegance of comprehensions. On 15 Apr 2015, at 20:27, Mark S. Miller erig...@google.com wrote: Dave Herman did an excellent presentation at one of the TC39 meetings that convinced us all to drop comprehension syntax from ES6. I remember it surprised us all including, earlier Dave, which led to his presentation. Anyone have a link? The arguments that I remember as most significant are a) When you look as how much syntactic convenience comprehensions provide above explicit calls to higher-order operations (assuming we have .map, .filter, as well as the currently absent .flatMap) and arrow functions, the answer is not much. b) When your comprehensions involve only those ho operations, fine. But as soon as you try to mix in some other ho operation, such as e.g., a reduce, if you started with a comprehension you're gonna create a mess. OTOH, if you were starting with code explicitly calling ho operations, then there's nothing confusing or unnatural mixing in some others. IMO, #a was necessary to convince me. YAGNI. Given #a, #b was sufficient. Dave, if I've misrepresented you in any way, please correct. Thanks. On Wed, Apr 15, 2015 at 10:20 AM, Axel Rauschmayer a...@rauschma.de mailto:a...@rauschma.de wrote: It’s important to keep in mind that there is no official version of array comprehensions, at the moment. So that is something to keep in mind whenever they are added to the language. I’d probably implement flatMap() and use it if I ever needed to do something like this. On 15 Apr 2015, at 18:34, Tab Atkins Jr. jackalm...@gmail.com mailto:jackalm...@gmail.com wrote: On Wed, Apr 15, 2015 at 9:31 AM, Jeremy Martin jmar...@gmail.com mailto:jmar...@gmail.com wrote: Why not just `[...x, ...y]`? Obviously that's a solution to the trivial example that monolithed provided, but it's not a solution to the more general problem he's alluding to, where you're doing a comprehension and want to insert two or more elements into the result in a single iteration. ~TJ ___ es-discuss mailing list es-discuss@mozilla.org mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer a...@rauschma.de mailto:a...@rauschma.de rauschma.de http://rauschma.de/ ___ es-discuss mailing list es-discuss@mozilla.org mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
ModuleSpecifier: include .js or not?
In Node.js you can either mention the file extension .js or omit it when you require a module. Which one is preferred for ES6 ModuleSpecifiers? Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: super() on class that extends
The reason why you need to call the super-constructor from a derived class
constructor is due to where ES6 allocates instances – they are allocated by/in
the base class (this is necessary so that constructors can be subclassed that
have exotic instances, e.g. `Array`):
```js
// Base class
class A {
// Allocate instance here (done by JS engine)
constructor() {}
}
// Derived class
class B extends A {
constructor() {
// no `this` available, yet
super(); // receive instance from A
// can use `this` now
}
}
// Derived class
class C extends B {
constructor() {
// no `this` available, yet
super(); // receive instance from B
// can use `this` now
}
}
```
If you do not call `super()`, you only get into trouble if you access `this` in
some manner. Two examples:
```js
// Derived class
class B1 extends A {
constructor() {
// No super-constructor call here!
// ReferenceError: no `this` available
this.foo = 123;
}
}
// Derived class
class B2 extends A {
constructor() {
// No super-constructor call here!
// ReferenceError: implicit return (=access) of `this`
}
}
```
Therefore, there are two ways to avoid typing super-constructor calls.
First, you can avoid accessing `this` by explicitly returning an object from
the derived class constructor. However, this is not what you want, because the
object created via `new B()` does not inherit `A`’s methods.
```js
// Base class
class A {
constructor() {}
}
// Derived class
class B extends A {
constructor() {
// No super-constructor call here!
return {}; // must be an object
}
}
```
Second, you can let JavaScript create default constructors for you:
```js
// Base class
class A {
}
// Derived class
class B extends A {
}
```
This code is equivalent to:
```js
// Base class
class A {
constructor() {}
}
// Derived class
class B extends A {
constructor(...args) {
super(...args);
}
}
```
On 10 Apr 2015, at 22:51, Jacob Parker jacobparker1...@gmail.com wrote:
Why was this a requirement? I have a class, we’ll call a, which I want to
extend from b, but I don’t want to call the constructor. I just want to
inherit a few functions from it.
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: super() on class that extends
No engine has implemented subclassing of `Array`, yet:
http://kangax.github.io/compat-table/es6/#Array_is_subclassable
http://kangax.github.io/compat-table/es6/#Array_is_subclassable
And, as Sebastian mentioned, you can’t transpile it, because it depends on the
cooperation of `Array`: it becomes the base constructor and allocates an exotic
array instance (with special handling for `length` etc.) whose prototype is
`new.target`.
Axel
On 11 Apr 2015, at 03:57, Garrett Smith dhtmlkitc...@gmail.com wrote:
On 4/10/15, Axel Rauschmayer a...@rauschma.de wrote:
The reason why you need to call the super-constructor from a derived class
constructor is due to where ES6 allocates instances - they are allocated
by/in the base class (this is necessary so that constructors can be
subclassed that have exotic instances, e.g. `Array`):
Can you please explain how extending Array works. Also what is the
optional identifier optional for in ClassExpression:
var myArray = (new class B extends Array {
constructor() {
super(1,2,3,4,5);
}
});
alert(myArray.length); // it's 0 in Babel.
--
Garrett
@xkit
ChordCycles.com
garretts.github.io
personx.tumblr.com
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Well-Known Symbols: Array item getter/setter
Proxies should be enough for this. Is there any reason not to use them?
On 09 Apr 2015, at 20:31, Kos Ddsky kos...@gmail.com wrote:
( note: you can view this message as a gist @
https://gist.github.com/kosich/375da99403c76bc75bbd
https://gist.github.com/kosich/375da99403c76bc75bbd )
Currently we can imitate Arrays only with objects, where we would refer to a
value at some position via referring to objects property ( with integer index
being converted to a string )
```js
var arr = {
0 : zero,
1 : one
};
arr[ 1 ];
```
But we wouldn't get all those features that original Array has (like length
autoincremention, splice, split etc.)
So, the suggestion is to have WKS for getting and setting item in array by
index.
```js
get [ Symbol.Array.item ] ( index ){ /*returning code here*/ }
set [ Symbol.Array.item ] ( index ){ /*setter code here*/ }
```
-or-
```js
[ Symbol.Array.get ] ( index ){ /*returning code here*/ }
[ Symbol.Array.set ] ( index ){ /*setter code here*/ }
```
## Possible usecases
### readonly array
will throw if user tries to set item directly via index
```js
class ROArray extends Array {
constructor( initialValues ){
// init the array values here
}
[ Symbol.Array.set ] ( index ){
throw 'can`t set';
}
[ Symbol.Array.get ] ( index ){
return this[ index ];
}
}
```
### template-like behavior
items getter will wrap the value into a tag
```js
class LITemplateArray extends Array {
set tag ( tag ){
this._tag = tag;
}
[ Symbol.Array.get ] ( index ){
var tag = this._tag || 'li',
value = this[ index ];
return `${ tag }${value}/${tag}`;
}
}
```
/*this is my first thread here, so I'm sorry if being wrong somewhere*/
/*after googling around, I haven't found such suggestion. though could easily
miss that*/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Well-Known Symbols: Array item getter/setter
An alternative that was discussed at one point was to invert this idea: * Arrays get the methods that Maps already have: `get(index)` and `set(index, value)`. Advantage: one could support negative indices. That is, the following two expressions would be equivalent. ```js arr.get(-1) arr.get(arr.length-1) ``` * Using brackets for accessing array elements is phased out. That may be easier to achieve and would fit in well with ES6 collections. On 09 Apr 2015, at 21:38, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Apr 9, 2015, at 2:37 PM, Jordan Harband ljh...@gmail.com mailto:ljh...@gmail.com wrote: One advantage of this approach is that more spec magic can be implemented in terms of the language - it would also make subclassed arrays more versatile instead of having to always be a Proxy. see http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The ES6 iteration protocol
There are two different aspects: 1. If you get an iterable, it sometimes matters whether iteration restarts when you ask the iterable for an iterator. 2. Self-iterability is how iterators turn themselves into iterables so that constructs that work with iterables can be used. It also enables generators to play two roles: generator methods can implement `[Symbol.iterator]` and generator functions can implement iterable-returning functions. In this particular case, I’m interested in #1. I probably have to come up with a better term for it. On 06 Apr 2015, at 23:30, Dmitry Soshnikov dmitry.soshni...@gmail.com wrote: Exactly, that's what I tried to explain. Since in one case it considers just an iterable (an array), and in other case -- an iterator (which is by coincidence is also an iterable). But an array's iterator is an iterable as well, and also always returns itself for iterator protocol. Yeah, the self-iterable makes much more sense in this case. Dmitry On Monday, April 6, 2015, Allen Wirfs-Brock al...@wirfs-brock.com mailto:al...@wirfs-brock.com wrote: On Apr 6, 2015, at 2:23 PM, Dmitry Soshnikov dmitry.soshni...@gmail.com javascript:; wrote: I guess all built-in iterators return themselves for `Symbol.iterator` protocol. So they are all singletons. I described in detail where confusion/substitution of concepts happens in that analysis in the recent two comments. I don’t think “singleton” is the correct term for the concept that Axel is trying to describe. A “singleton” is normally an kind of object for which there is only a single instances. There may be many instances of, for example %ArrayIterator%, so it isn’t correct to call %ArrayIterator% a singleton What Axel is describing might be characterized as “self iterable”, it returns itself when recieving a Symbol.iterator request. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `of` operator ES7 proposal from Ian Bicking
* Name-wise, is `has` a possibility? It feels more intuitive and I don’t think the duality with `in` matters (given that `for-in` will probably rarely be used in the future, due to `for-of` and `Map`). * Will it ever be possible to define arbitrary infix operators? If yes, should this operator wait until that feature is available? On 30 Mar 2015, at 07:20, Brendan Eich bren...@mozilla.org wrote: From https://plus.google.com/+IanBicking/posts/PbXDtNF9Gg6: Ian Bicking Shared publicly - Mar 24, 2015 #Array Huh, for (attr in obj) goes along with if (attr in obj), but for (item of array) doesn't have an equivalent if (item of array) There is a proposal I guess for a method, but only for ES7: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/includes It's obvious in hindsight. Wants a @@hasInstance-like protocol, not just desugaring to `includes` with operands transposed to receiver and argument. An `of` operator with unstratified symbol-named MOP hook helps various container-like objects cope with the vagaries of NaNs and indexOf / includes differences between arrays and strings, and (most winningly) lines up with for-of, as Ian points out, in a parallel to for-in and `in`. I'm sure it's worth some debate, perhaps someone will k.o. the idea with an objection I can't think of, but I like it. /be -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Determine if a value is Callable/Constructible
There is no intrinsic reason why we needed to mandate that class constructors should throw when called. We even provided a simple and straight forward way (new.target===undefined) that a ES constructor body can use to determine whether it was called or new’ed. I think we should just drop that throws when called feature of class constructors.. (The restriction was added to future proof for the possibility of inventing some other way to provide a class with distinct new/call behavior. I don’t think we need nor can afford to wait for the invention of a new mechanism which will inevitably be more complex than new.target, which we already have.) I don't think this is an accurate representation of the discussion we had. Any other reasons for throwing? It’d be great to know what they were! -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Determine if a value is Callable/Constructible
It doesn’t seem that big of a deal, but one risk is: people mistaking a class for a constructor, trying to subclass it as if it were a constructor and things failing silently. On 30 Mar 2015, at 07:49, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Mar 29, 2015, at 11:51 PM, Caitlin Potter caitpotte...@gmail.com wrote: ... Reflect.isConstructor(fn) - true if Class constructor, generator, or legacy (and non-builtin) function syntactic form Reflect.isCallable(fn) - true for pretty much any function, except for class constructors and a few builtins I’ve already seen another situation (node’s Buffer) where code could be simplified by using a ES6 class definition but where that is prevented because a class constructor throws when called. Just to clarify something. Class constructors actually are “callable”. You can observe this by the fact that Proxy allows you to install an “apply” handler (the reification of the [[[Call]] internal method) on a class constructor. The the fact that an object can be [[Call]]’ed is already reflected by the typeof operator. Class constructors throw when called because at the last minute we choose to make their [[Call]] do an explicit throw not because they aren’t callable. There is no intrinsic reason why we needed to mandate that class constructors should throw when called. We even provided a simple and straight forward way (new.target===undefined) that a ES constructor body can use to determine whether it was called or new’ed. I think we should just drop that throws when called feature of class constructors.. (The restriction was added to future proof for the possibility of inventing some other way to provide a class with distinct new/call behavior. I don’t think we need nor can afford to wait for the invention of a new mechanism which will inevitably be more complex than new.target, which we already have.) Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Determine if a value is Callable/Constructible
It doesn’t seem that big of a deal, but one risk is: people mistaking a
class for a constructor, trying to subclass it as if it were a constructor
and things failing silently.
Can you give an example of what you mean?
```js
class MySuperClass {}
// This function assumes that MySuperClass is an ES5 constructor function
function MySubConstructor(foo) {
MySuperClass.call(this);
this.foo = foo;
}
MySubConstructor.prototype = Object.create(MySuperClass.prototype);
MySubConstructor.prototype.constructor = MySubConstructor;
```
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Determine if a value is Callable/Constructible
```js
class MySuperClass {}
// This function assumes that MySuperClass is an ES5 constructor function
function MySubConstructor(foo) {
MySuperClass.call(this);
this.foo = foo;
}
MySubConstructor.prototype = Object.create(MySuperClass.prototype);
MySubConstructor.prototype.constructor = MySubConstructor;
```
so if MySuperCall didn’t have the throw on [[Call]] behavior the above would
work just fine.
In general, I’d expect this kind of subclassing to fail, due to the new
instantiation protocol. Wrong?
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Determine if a value is Callable/Constructible
On Mar 30, 2015 10:54 AM, Axel Rauschmayer a...@rauschma.de wrote:
```js
class MySuperClass {}
// This function assumes that MySuperClass is an ES5 constructor function
function MySubConstructor(foo) {
MySuperClass.call(this);
this.foo = foo;
}
MySubConstructor.prototype = Object.create(MySuperClass.prototype);
MySubConstructor.prototype.constructor = MySubConstructor;
```
so if MySuperCall didn’t have the throw on [[Call]] behavior the above
would work just fine.
In general, I’d expect this kind of subclassing to fail, due to the new
instantiation protocol. Wrong?
Would work fine if throw semantics removed and invoked as
```js
new MySubConstructor();
```
Just like ES5.
If invoked as
```js
MySubConstructor();
```
would fail just like ES5.
Throwing on [[Call]] is a compatibility hazard.
Don’t the different assumptions as to where the instance is allocated ever
clash here? What if `MySuperClass` were:
```js
class MySuperClass extends Error {
}
```
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Determine if a value is Callable/Constructible
Don’t the different assumptions as to where the instance is allocated ever
clash here? What if `MySuperClass` were:
```js
class MySuperClass extends Error {
}
```
MySubClass preallocates when invoked via new. Just like ES5. So,
```MySuperClass.call(this)``` is same as ES5. What happens in MySuperClass
depends upon the ES6 level programmer.
Right, but I don’t see how an ES5-style constructor MySubContructor can
allocate its instance and then have it initialized by an ES6 class (where the
instance is allocated by a super-class). This is about ES5 code being
confronted with ES6 code and assuming to see a constructor.
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Determine if a value is Callable/Constructible
In some way, that would even be correct – depending on what you expect a function to be: something callable or something constructible. Alas, there is currently no simple way to distinguish “callable” and “constructible”. Why do you say they're not callable? As in “makes sense to call”. In the past, `typeof x === 'function'” was an adequate test for checking whether it makes sense to call `x`. Since ES6, it isn’t, anymore. That’s why the checks proposed by Caitlin will be nice to have. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Determine if a value is Callable/Constructible
If you made them non-callable by not implementing [[Call]], then typeof would no longer return function, which would be ... O_o. In some way, that would even be correct – depending on what you expect a function to be: something callable or something constructible. Alas, there is currently no simple way to distinguish “callable” and “constructible”. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
The ES6 iteration protocol
FWIW: I have written down my understanding of the ES6 iteration protocol (shaped by discussions I had on this mailing list). https://gist.github.com/rauschma/73e5f86a595b7709f39e -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promises vs Streams
Synchronously, we have both normal (synchronous) function calls and iteration over a sequence of values (via `for-of` and iterators). It makes sense that we also should have two abstractions for asynchronous interaction. On 28 Mar 2015, at 13:14, Boopathi Rajaa legend.r...@gmail.com wrote: I feel this must have already been discussed but couldn't find any discussion threads, just trying to understand them better. The basic doubt is that I feel promises are more like streams, and that streams are much more powerful than promises. With a promise you have a value or an exception, and with a stream, you have a list of values or an exception. Why do we have both ? or more specifically, since we have both, when to use Promises and when to use Streams ? Whatever I imagine to be a Promise can be thought out to be solved by Streams, and sometimes whenever I use streams, it feels like I'm using similar API as Promises. - Boopathi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Forwarding `return()` in generators
We want `return` (Python 2.5+ close) to be optional, though. So an iterator
whether implemented by a generator function or otherwise sees no difference
-- provided in the generator function implementation you do not yield in a
try with a finally. Forcing return from a not-exhausted generator parked at
yield other than in try-with-finally does not run any more code in the
generator function's body.
`return()` being optional is true for arrays:
```js
function twoLoops(iterable) {
let iterator = iterable[Symbol.iterator]();
for (let x of iterator) {
console.log(x);
break;
}
for (let x of iterator) {
console.log(x);
break;
}
}
twoLoops(['a', 'b', 'c']);
// Output:
// a
// b
```
But it is not true for generators:
```js
function* elements() {
yield 'a';
yield 'b';
yield 'c';
}
twoLoops(elements());
// Output:
// a
```
That is a difference between iterators that you have to be aware of and that
needs to be documented per iterable. It’d be great if all iterables were indeed
the same in this regard.
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Forwarding `return()` in generators
It’d be great if all iterables were indeed the same in this regard. What do you suggest, that array iterators should not be continuable? So we'd have `.return()` methods on ArrayIterators, StringIterators, MapIterators, and SetIterators, which sets the respective [[Iterated*]] internal property to `undefined`? Maybe I overstated, maybe documenting whether an iterable produces continuable iterators is enough, but it is something to be aware of, something that has to be explained in conjunction with the iteration protocol. Similarly: whether an iterable restarts iteration every time you call `[Symbol.iterator]()` (generators don’t restart, arrays do). -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Iterating default function arguments
I'm all for using Reflect, but looking at the API as listed on MDN, the
harmony-reflect github, or the spec, i don't see an obvious way of getting
the parameters.
If I understand you correctly (and this is not about parsing the parameter
definitions) then how about the following solution?
```js
function foo(…args) {
let [a, b = 2] = args;
return args;
}
```
Original code:
```js
function foo( a, b = 2 ) {
return arguments;
}
```
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Forwarding `return()` in generators
But: you need to guard against other ways of reaching `finally`. Why? I intended to always reach finally, and always close the iterator. Also, simplicity ftw :-) That’s not what all the other constructs in ES6 do: they only call `return()` if iteration stops abruptly. Only because all the other constructs in ES6 try to exhaust the iterator. And when it's finished anyway, one doesn't need to close it. There is in fact no problem with calling `.return()` too often, it just doesn't do anything to completed generators. True. I hadn’t thought of that. Btw, your `take` function is the perfect example where a non-exhausted iterator *should* be closed as return prematurely - like a `break` in a for-of loop would. Right. Always closing is much simpler. Otherwise, you’d have to check whether everything was exhausted or not. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Always close iterators?
Given that redundant calls to `return()` don’t make a difference (h/t Bergi),
wouldn’t the iteration protocol be simpler if iterators were always closed
(versus only if iteration finishes abruptly). The code of generators wouldn’t
change (`finally` etc.), but “manually implemented” iterators could be written
without the check in line (A). They’d become simpler and more similar to
generators and `finally`.
```js
let iterable = {
[Symbol.iterator]() {
return {
next() {
if (iterationIsDone()) {
return { done: true };
} else {
let result = { value: nextValue(), done: false };
if (iterationIsDone()) { // (A)
cleanUp();
}
return result;
}
},
return(value) {
if (! iterationIsDone()) {
cleanUp();
}
return { value: value, done: true };
}
}
}
}
```
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Forwarding `return()` in generators
Good point, if it is about iteration, only `return()` needs to be propagated.
On 24 Mar 2015, at 23:35, Ron Buckton ron.buck...@microsoft.com wrote:
Is your goal to wrap a generator, as it seems you are propagating the
exception of the caller by calling iterator.throw(). However, you do not seem
to be propagating the sent value, so the protocol here isn’t fully
implmeneted.
If you just want to iterate values (and don’t really care about the return
value of the iterable or propagating a thrown exception, you could write:
```js
function* take(n, iterable) {
n |= 0;
if (n = 0) {
return;
}
// let for..of call return()
for (let value of iterable) {
yield value;
if (n-- = 0) {
return;
}
}
}
```
If you want to support the full communication channel of a generator, you
could write:
```js
function* take(n, iterable) {
let iterator = iterable[Symbol.iterator]();
let step = () = iterator.next();
n |= 0;
// try..finally outside of loop
try {
let sent;
while (n 0) {
let { value, done } = step();
if (done) {
return value;
}
n--;
// try..catch local to the yield
try {
sent = yield value;
step = () = iterator.next(sent);
}
catch (e) {
if (typeof iterator.throw === function) {
step = () = iterator.throw(e);
}
else {
throw e;
}
}
}
}
finally {
if (typeof iterator.return === function) {
iterator.return();
}
}
}
```
From: es-discuss [mailto:es-discuss-boun...@mozilla.org
mailto:es-discuss-boun...@mozilla.org] On Behalf Of Axel Rauschmayer
Sent: Tuesday, March 24, 2015 2:28 PM
To: Bergi
Cc: es-discuss list
Subject: Re: Forwarding `return()` in generators
Right, it doesn’t look like one needs to know the returned value when
forwarding `return()`.
But: you need to guard against other ways of reaching `finally`. Maybe like
this:
```js
function* take(n, iterable) {
let iterator = iterable[Symbol.iterator]();
n = +n; // make sure it's a number, so that n0 does never throw
let forwardReturn = true;
try {
while (n 0) {
let item = iterator.next();
if (item.done) {
forwardReturn = false;
return item.value;
}
yield item.value;
n--;
}
forwardReturn = false;
} catch (e) {
forwardReturn = false;
iterator.throw(e);
} finally {
if (forwardReturn) {
iterator.return();
}
}
}
```
The above code also has the additional nice property that it call `.return()`
on the iterator when `n` values have been taken out of it.
That’s not what all the other constructs in ES6 do: they only call `return()`
if iteration stops abruptly.
Also missing from this code: checking whether the iterator actually has the
methods `return()` and `throw()` and responding accordingly.
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Forwarding `return()` in generators
Right. Always closing is much simpler. Otherwise, you’d have to check
whether everything was exhausted or not.
This is by design, FWIW.
Which is OK, I’m more worried about generators behaving differently in reaction
to `return()` than, e.g., array iterators. With the latter, you can continue
iterating if you break from a `for-of` loop, with the former, you (generally)
can’t. Either behavior is OK, but it should be consistent: Is `return()` for
optional clean-up (array iterators) or does it really close an iterator
(generators)?
The way that `return()` is handled in generators (via try-catch) means that the
clean-up action is called in both cases: generator exhaustion and generator
closure. If you don’t use a generator then a clean-up action in `return()` is
only called if the iterator is closed, not if it is exhausted. Obviously that
is a minor technical detail and easy to fix (call the clean-up action when you
return `{ done: true }`), but it’s still an inconsistency (which wouldn’t exist
if `return()` was called in either case).
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Always close iterators?
Given that redundant calls to `return()` don’t make a difference (h/t Bergi) I'm sorry, that was not 100% accurate. Right, ignore that part of my email. My main argument is: “wouldn’t the iteration protocol be simpler if iterators were always closed (versus only if iteration finishes abruptly)?” -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Forwarding `return()` in generators
Right, it doesn’t look like one needs to know the returned value when
forwarding `return()`.
But: you need to guard against other ways of reaching `finally`. Maybe like
this:
```js
function* take(n, iterable) {
let iterator = iterable[Symbol.iterator]();
n = +n; // make sure it's a number, so that n0 does never throw
let forwardReturn = true;
try {
while (n 0) {
let item = iterator.next();
if (item.done) {
forwardReturn = false;
return item.value;
}
yield item.value;
n--;
}
forwardReturn = false;
} catch (e) {
forwardReturn = false;
iterator.throw(e);
} finally {
if (forwardReturn) {
iterator.return();
}
}
}
```
The above code also has the additional nice property that it call `.return()`
on the iterator when `n` values have been taken out of it.
That’s not what all the other constructs in ES6 do: they only call `return()`
if iteration stops abruptly.
Also missing from this code: checking whether the iterator actually has the
methods `return()` and `throw()` and responding accordingly.
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Forwarding `return()` in generators
AFAICT, `return()` throwing an exception (versus performing a `return`) is
necessary if you want to forward it like in the following code:
```js
function* take(n, iterable) {
let iterator = iterable[Symbol.iterator]();
try {
while (n 0) {
let item = iterator.next();
if (item.done) {
return item.value;
}
yield item.value;
n--;
}
} catch (e) {
if (e instanceof ReturnException) {
iterator.return(e.returnValue); // forward
}
···
}
}
```
Seems important w.r.t. composability of generators.
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Converting strings to template strings
But from the few data points I have, approximately 100% of web developers, when they first hear template strings are in ES6, think that means something like Mustache in the standard library. Some initially try to use the feature that way and get frustrated. I expect widespread confusion on this point. Pedagogically, a name change would make a lot of sense, yes! I’ve even seen fairly knowledgeable people get this wrong. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
What is `this` inside a new-invoked generator?
Question: what does the following code snippet log in the last line?
```js
function* gen() {
yield this;
}
let genObj = new gen();
let [_this] = genObj;
console.log(_this === genObj); // ???
```
I’m finding three answers:
1. The spec says [1] that any reference to `this` in a generator invoked via
`new` causes a `ReferenceError`.
2. Firefox logs `false` for the code snippet.
3. A year ago, Allen stated [2] that if you invoke a generator function via
`new`, `this` points to the generator object. On other words, the code snippet
would log `true`.
[1]
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-generator-function-definitions-runtime-semantics-evaluatebody
[2]
https://esdiscuss.org/topic/reason-why-generators-do-not-have-references-to-themselves#content-8
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
`import` and hoisting
As far as I can tell, `import` is hoisted (due to
`ModuleDeclarationInstantiation`). Is the following code OK, then? No temporal
dead zone?
```js
bar();
import {foo} from 'mymodule';
function bar() { // hoisted!
foo(); // already initialized?
}
```
How about this code?
```js
foo();
import {foo} from 'mymodule';
```
Thanks!
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: What is the difference between `newTarget` and `F` in abstract operation `Construct(..)` ?
They diverge if a constructor makes a super-constructor call: The last constructor in a chain of super-constructor calls allocates the instance and it has to use `newTarget.prototype` as the prototype. `newTarget` is first filled in by the `new` operator and later passed on by `super`. This is roughly similar to making super-method calls where `this` has to remain the same, because the super-method has to access the same instance properties. On 16 Mar 2015, at 18:32, Coolwust coolw...@gmail.com wrote: From ES 6, section 7.3.14, there is an abstract operation `Construct (F, [argumentsList], [newTarget])`, so if I have the following code `var foo = new bar()`, then `newTarget` is the same as `F`, which is `bar`. My question is, in what situation, `F` is **NOT** the same as `newTarget`? And what is `newTarget` really? -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How to fix the `class` keyword
What built-ins are we talking about then? Array, Map, Set, Promise come to mind offhand. Error is another one where subclassability will be handy. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: How to fix the `class` keyword
I’m saying the following as someone who does not think that classes are perfect (I dislike that they look so different from what they are internally translated to), but they will “just work” for most people and they are backwards-compatible with much current code. Make class inheritance compositional similar to the way stamps are composed. http://chimera.labs.oreilly.com/books/123400262/ch03.html#prototypal_inheritance_with_stamps In other words, change the behavior of `extend`, or deprecate `extend` and replace it with something like a `compose` keyword that can compose any number of classes. Traits (or mixins) are coming! A class will be the location where you assemble (any number of) traits. IMO, it’s better to have a different construct for this than to force classes to serve this use case. In my view, this is your most important point and traits are the answer. Deprecate `new`. `new` violates both the substitution principle and the open / closed principle. The `new` keyword is destructive because it adds zero value to the language, and it couples all callers to the details of object instantiation. If you start with a class that requires `new` (all classes in ES6) and you later decide you need to use a factory instead of a class, you can’t make the change without refactoring all callers. This is especially problematic for shared libraries and public interfaces, because you may not have access to all of the code using the class. You may think it doesn’t do any harm to just call a factory function with the `new` keyword, but the `new` keyword triggers behaviors that change what’s going on when the function is invoked. If you can’t count on the function to behave the same way for all callers, you can’t predict what the software will do. That’s bad. Make sure that `class` obeys the substitution principle when you switch from a class to a factory and vise verse. This is an important point, because if callers are counting on any behavior or property of a class, and you decide to change the implementation to a factory, you’ve just broken the calling code. Additionally, if callers are counting on the behavior of a factory, and you switch the implementation to a class, that’s similarly problematic, though as it stands, there’s no good reason to switch from a factory to a class. You can easily return an instance of a subclass or any other object from a class constructor. Engines can an will optimize this so that there won’t be any difference between a factory function and a class in this regard. In other words: you can make the changes you are describing. The behavior of `this`. It always refers to the new instance in a class constructor. In a factory function, `this` is dynamic, and follows a completely different set of rules. Possible solution: deprecate `this` and instead refer to the class or function by name. A major drawback of this solution is that it would break `.call()`, `.apply()` and `.bind()`, unless we also change their behavior to override the function name reference. This assumes that you want to go back and forth between classes and factory functions. If you don’t then `this` is not an issue. I know I've raised all these issues on es-discuss before and basically been told to go suck an egg, but we all want the same thing -- a better JavaScript for everybody. I agree. Classes do have drawbacks, but they also have advantages: static analyzability, backwards compatibility, the ability to subclass built-ins. I can clearly feel your passion, but you are not being completely fair w.r.t. their pros and cons. After traits (in ES7?), I don’t see anything *major* missing from your wish list. Things won’t be *exactly* like you want them, but you’ll be able to do everything you want to. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The result of Generator.prototype.return
All three generator methods do the same basic thing: they resume the generator with a completion and return the next-yielded-value (or the return value, if done is true). The only difference is which type of completion is used to resume the generator: normal, throw, or return. OK. I see the use case for `throw()` (e.g. to convert a promise rejection into an exception when using generators for async). The only use case for `return()` is closing an iterator, then(?) -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The result of Generator.prototype.return
On 25 Feb 2015, at 15:33, Kevin Smith zenpars...@gmail.com wrote: OK. I see the use case for `throw()` (e.g. to convert a promise rejection into an exception when using generators for async). The only use case for `return()` is closing an iterator, then(?) Or for closing a data sink, if you're using a generator that way. In particular, return is called on an iterable in the event of an early exit from a for-of loop, in order to allow the iterable to release resources or perform other cleanup. Right (also: destructuring, spread, etc.). I was mainly wondering whether there was any other use case for `return()`. Axel -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
`new Set()` or `new Map()` with more than one argument
I’ve accidentally created the wrong set a few times:
```js
let set = new Set('red', 'green', 'blue');
// WRONG: same as new Set(['r', 'e', 'd'])
```
Would it make sense to throw if either of the constructors `Set` and `Map`
receives more than one argument?
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype change (Was: @@toStringTag spoofing for null and undefined)
On 19 Feb 2015, at 21:09, Andrea Giammarchi andrea.giammar...@gmail.com wrote: if we'd like to have Array.empty, Function.empty, String.empty and friends, what's wrong with having these as we always had already: as prototypes? I find it more self-explanatory. Here, prototypes are taking on a role that they don’t usually have: they are empty instances of “their” constructors. A much more important reason, though, is that you want to freeze everything `*.empty`, because these instances will get shared and then mutability is a problem. However, you can’t freeze `Array.prototype`. Greetings, Axel -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: extends null
Making it a dynamic error at class definition time to extend null would work
but the motivation for not doing that was that someone might want to create a
class that has a {__proto__: null} prototype. Personally, I would be fine
with saying that this case is so rare that it would be better to have that
dynamic error at class definition time.
Interesting. I have never seen this pattern and don’t see what it could be good
for. Thus, a dynamic error at class definition time sounds good to me.
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
extends null
If I’m reading the latest spec draft correctly then
```js
class C extends null {
}
```
produces the following result:
1. Constructor kind: derived
2. Prototype of `C`: `Function.prototype`
3. Prototype of `C.prototype`: `null`
Neither #2 nor #3 seems very useful:
* #2 means that a super-constructor call is allowed but throws an exception,
because `Function.prototype` is not constructible. The default constructor will
perform a super-constructor call. As a result, you are forced to explicitly
return an object from the constructor if you don’t want an exception to be
thrown.
* #3 means that the constructor doesn’t even create objects whose prototype is
`null`, but objects whose prototype is an object whose prototype is `null`.
Therefore my question: is this useful for anything? Can’t `extends null` be
turned into something useful? Even treating `extends null` as equivalent to a
missing `extends` clause seems preferable.
Thanks!
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: extends null
But it’s not an error! Either of the following two classes fail later, when you
instantiate them, but not right away.
```js
const X = null;
class C extends X {}
class D extends null {}
```
I’m arguing that both produce weird constructors. I’d much prefer an early
error. Or dynamically switching from derived to base (but you seem to be
saying that doing this dynamically is not a good idea).
On 14 Feb 2015, at 22:05, Mark S. Miller erig...@google.com wrote:
No, the problem is that
class C extends X {
when X turns out to be null must be an error along exactly these lines.
Everywhere else in the language where X is accepted as an expression
evaluated to a value, if X evaluates to null, this is the same thing as
placing null in that position. Consider:
const NULL = null; // C nostalgia
class C extends NULL {
It would be awful for this to be different than
class C extends null {
If you really want to write a class whose prototype.__proto__ is null,
imperatively make it so after the class declaration. We don't need to
compromise the consistency of the language to make this rare case less ugly.
On Sat, Feb 14, 2015 at 12:52 PM, Axel Rauschmayer a...@rauschma.de
mailto:a...@rauschma.de wrote:
If I’m reading the latest spec draft correctly then
```js
class C extends null {
}
```
produces the following result:
1. Constructor kind: derived
2. Prototype of `C`: `Function.prototype`
3. Prototype of `C.prototype`: `null`
Neither #2 nor #3 seems very useful:
* #2 means that a super-constructor call is allowed but throws an exception,
because `Function.prototype` is not constructible. The default constructor
will perform a super-constructor call. As a result, you are forced to
explicitly return an object from the constructor if you don’t want an
exception to be thrown.
* #3 means that the constructor doesn’t even create objects whose prototype
is `null`, but objects whose prototype is an object whose prototype is `null`.
Therefore my question: is this useful for anything? Can’t `extends null` be
turned into something useful? Even treating `extends null` as equivalent to a
missing `extends` clause seems preferable.
Thanks!
Axel
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Property names for public symbols
Got it: public symbols stand for property names and those are typically camel-case, starting with a lowercase letter. On 08 Feb 2015, at 02:09, Brendan Eich bren...@mozilla.org wrote: Axel Rauschmayer wrote: Can you explain what you mean by “same-named”? You want `Symbol.for()` to have the same casing as `Symbol.iterator`? No, I mean we would normally use iterator (and had __iterator__ in SpiderMonkey, then '@@iterator' I believe), not ITERATOR. Python's dunder-bracketing doesn't cut it, symbols win. But UPPERCASE loses. /be -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Property names for public symbols
This symbol is about the string tag. On 08 Feb 2015, at 14:05, Mark Volkmann r.mark.volkm...@gmail.com wrote: I'm curious why one of the public symbols has a name that ends with Tag (toStringTag), but the others don't (such as toPrimitive). Maybe toStringTag should be changed to toString. __ __ / \/ \ \ /ark Object Computing, Inc. \ / \/olkmann -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Property names for public symbols
Can you explain what you mean by “same-named”? You want `Symbol.for()` to have the same casing as `Symbol.iterator`? On 07 Feb 2015, at 02:17, Brendan Eich bren...@mozilla.org wrote: Some tasteful inconsistency (the hobgoblin of big minds) is required here. We want the well known symbols' names as static properties of Symbol to be same-named. /be Mark Volkmann wrote: Agreed, like at the constants on the Math object. --- R. Mark Volkmann Object Computing, Inc. On Feb 6, 2015, at 12:39 AM, Axel Rauschmayer a...@rauschma.de mailto:a...@rauschma.de wrote: I know that this is a small nit and that it’s probably too late, but: Shouldn’t public symbols (`Symbol.iterator` etc.) have all-uppercase property names? It would indicate that they are constants and it would visually set them apart from other stuff that is in `Symbol` (`Symbol.for()` etc.). -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Property names for public symbols
I know that this is a small nit and that it’s probably too late, but: Shouldn’t public symbols (`Symbol.iterator` etc.) have all-uppercase property names? It would indicate that they are constants and it would visually set them apart from other stuff that is in `Symbol` (`Symbol.for()` etc.). -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Should `use strict` be a valid strict pragma?
Also: given that modules are implicitly strict, you will hardly ever use the
strict directive in ES6.
On 05 Feb 2015, at 20:20, Steve Fink sph...@gmail.com wrote:
On 02/05/2015 05:12 AM, Andy Earnshaw wrote:
I think you're missing the point Leon is trying to make. He's saying that,
in ES 6 we have a new way to write strings. In some ways, these more
powerful strings may condition some people to use ` as their main string
delimiter. An unsuspecting person may liken this to PHP's double quotes vs
single quotes, thinking that the only difference is that you can use
`${variable}` in strings that are delimited with backticks, but other than
that everything is the same. When they write this in their code:
```
`use strict`;
```
They may introduce bugs by writing non-strict code that doesn't throw when
it should. Adding it to the spec wouldn't be difficult and it would avoid
any potential confusion or difficult-to-debug issues. It's definitely
easier than educating people, IMO.
'use strict' and use strict are magic tokens and should stay that way, not
propagate to other ways of writing literal strings. Literal strings are
different things, which happen to share the same syntax for
backwards-compatibility reasons.
If people switch to backticks for all their literal strings, so much the
better -- then single and double quotes will only be used for directives, and
there will be less confusion. (I don't actually believe that. At the very
least, I don't expect JSON to allow backticks anytime soon. Nor do I think
that using backticks indiscriminately is good practice.)
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Informative notes
Regarding the general idea of motivation/introductory materials, I think the new process explicitly encourages this, and indeed most new proposals include that in their README or similar. Examples: - https://github.com/tc39/Array.prototype.includes/blob/master/README.md - https://arv.github.io/ecmascript-object-observe/#intro - https://github.com/rwaldron/exponentiation-operator - https://github.com/lukehoban/ecmascript-asyncawait https://github.com/lukehoban/ecmascript-asyncawait I agree, these are all great. They’ll be an important complement to the spec. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Informative notes
On 22 Jan 2015, at 10:29 , Brendan Eich bren...@mozilla.org wrote: ECMA-357 (E4X) pioneered informative-first prose sections, not found in ECMA-262 Ed. 3, and as a direct consequence, had too many imprecise or even inaccurate informative notes, which (turns out) were misread as normative, or simply otherwise caused confusion. OTOH, I find rationales and complete terminology very important for talking about and understanding the spec (but I do know that that would incur even more work). At the moment, reading the spec feels like figuring out undocumented source code; rationales have to be deduced by going though the TC39 meeting notes and the es-discuss archives (or, in the case of proxies, Tom’s papers). A companion book to ECMA-262 may be the ideal solution, but the problem is that the audience/market for such a book is small. And Allen’s plate must be full enough as it is. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Informative notes
Follow-up thought: people still link to the (completely outdated) proposals on the wiki, because they are often very readable. Is it conceivable to better maintain proposals for ES2016+ ? Or would that be too much work for the champions? On 02 Feb 2015, at 19:50 , Axel Rauschmayer a...@rauschma.de wrote: On 22 Jan 2015, at 10:29 , Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org wrote: ECMA-357 (E4X) pioneered informative-first prose sections, not found in ECMA-262 Ed. 3, and as a direct consequence, had too many imprecise or even inaccurate informative notes, which (turns out) were misread as normative, or simply otherwise caused confusion. OTOH, I find rationales and complete terminology very important for talking about and understanding the spec (but I do know that that would incur even more work). At the moment, reading the spec feels like figuring out undocumented source code; rationales have to be deduced by going though the TC39 meeting notes and the es-discuss archives (or, in the case of proxies, Tom’s papers). A companion book to ECMA-262 may be the ideal solution, but the problem is that the audience/market for such a book is small. And Allen’s plate must be full enough as it is. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Question about Symbols and GlobalSymbolRegistry
On 28 Jan 2015, at 00:06, Brendan Eich bren...@mozilla.org wrote: Axel Rauschmayer wrote: It may make sense to add them. Their identifiers would have to be as unambiguous as possible, e.g. URIs such as http://ecmascript.org/symbol/foo;. Symbol.iterator and the other well-known symbols are self-same in all connected realms. See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-well-known-symbols. So there's no need for this There is one use case (admittedly a rather hypothetical one): serializing the Symbol.* symbols to a text format (e.g. an encoding in JSON). (and URLs suck for such things; plus, you probably mean URIs, but I don't care enough to check!). Yes, I mean URIs(?) -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Question about Symbols and GlobalSymbolRegistry
It may make sense to add them. Their identifiers would have to be as
unambiguous as possible, e.g. URIs such as http://ecmascript.org/symbol/foo
http://ecmascript.org/symbol/foo.
On 27 Jan 2015, at 23:55, Jordan Harband ljh...@gmail.com wrote:
They are not - if they were, then adding a new well-known symbol like
Symbol.foo would fail if anyone had code that did `Symbol.for('foo')`. (I
have no idea if that is the reason, but certainly that's a reason not to make
them available via the registry)
On Tue, Jan 27, 2015 at 2:32 PM, Cyrus Najmabadi cyr...@microsoft.com
mailto:cyr...@microsoft.com wrote:
Hi esdiscuss. A couple more questions.
1) Are the built-in symbols (like ‘Symbol.iterator’) in the
GlobalSymbolRegsitry?
2) If so, what are their keys? i.e. how would one reach Symbol.iterator
using Symbol.for(…)?
Thanks!
-- Cyrus
From: Kevin Smith [mailto:zenpars...@gmail.com mailto:zenpars...@gmail.com]
Sent: Wednesday, January 21, 2015 5:16 PM
To: Cyrus Najmabadi
Cc: Jason Freeman; es-discuss
Subject: Re: Question about Symbols and GlobalSymbolRegistry
Am I understanding correctly?
Yes. The argument to the Symbol constructor is just a descriptive string.
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: JavaScript 2015?
The spec is no longer called ES6. The marketing hasn’t really begun to educate the community about this yet, but the spec is called ES 2015. OK, good to know. Does it make sense to normally refer to it as “JavaScript 2015”, then? As for your concern about 2015 seeming old in 2016: **good**. In 2016, we’ll be publishing ES 2016, and ES 2015 will be missing a lot* of stuff that ES 2016 has! * hopefully. Even ignoring books, I don’t share that attitude: for programming languages, a slower pace is good. It took people a long time to get used to ES5 and ES 2015 will have many more new features. It will take time to: * Completely implement ES 2015 * Write proper material * Educate people * Establish modules (I’m seeing browser APIs based on promises, but none that are based on modules) Axel -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JavaScript 2015?
This seems just fine, not a problem. Yet at least for a while, possibly longer than some TC39ers think, people will still say ES6. I find Andrea's WTF to be overdone, overstated -- but we shall find out. Even TC39 can make changes based on wider feedback, after it has made a decision. The idea of a community-approved name or naming scheme brings to mind that Axel wished for a community-managed trademark. Be careful what you wish for. The Ecma TC39 renaming process (like just about any other TC39 decision process) was not community-driven, with a lengthy propose/listen/dispose cycle and some kind of open governance (however defined). Rather, we're still doing consensus among a mix of pay-to-play and not-for-profit standard body members, where members have to build trust among developers and work in Harmony, at least in the modern post-ES4 era. Renaming angst, which could become an issue or just blow up for some reason we can't foresee, is just one issue to address for the same of developer trust and harmony. I have never advocated design or naming by popular vote! I don’t care what ES7 is called, but I have to decide soon on what to put on the cover of an ES6 book and that cover will either be inspired by a 6 or by a 2015. This may seem trivial to others, but for me it is a real decision, which involves quite a bit of money. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JavaScript 2015?
Two different issues: * I agree that renaming ES.next this late will be difficult * The smaller incremental releases have been planned for a while [1] and make sense: only if something is mostly done in most browsers does it become part of the standard. That is, releases are driven by features not the other way around. How often is debatable, but small and incremental is good. [1] https://github.com/tc39/ecma262 https://github.com/tc39/ecma262 (esp. link “this process document”) On 23 Jan 2015, at 01:11, Andrea Giammarchi andrea.giammar...@gmail.com wrote: I really don't understand ... Draft ECMA-262 6th Edition https://people.mozilla.org/~jorendorff/es6-draft.html https://people.mozilla.org/~jorendorff/es6-draft.html ECMAScript 6 support in Mozilla https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/ECMAScript_6_support_in_Mozilla https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/ECMAScript_6_support_in_Mozilla ES6 Rocks http://es6rocks.com/ http://es6rocks.com/ Books already published, years of blog-posts all over the internet educating developers about ES6 features. A clear deadline in terms of features instead of year since by the end of 2015 I am pretty sure no engine will be fully spec-compliant with the spec. What is this new back to year-versioning approach? Why suddenly we need a full new release each year when it took 15 years to have full ES3 support from all vendors? This feels like Adobe and the AS1 to AS3 era, the one that lost most developers due inability to catch up with anything and confusion across just specs. And that was a single vendor proposing new features for its language, I cannot imagine where this is going. /rant Best Regards On Fri, Jan 23, 2015 at 12:02 AM, Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org wrote: Harmony refers to the whole post-ES4 consensus-based arc of specs from ES5 (neé 3.1) onward into the future, until done ;-). See https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html https://mail.mozilla.org/pipermail/es-discuss/2008-August/006837.html ECMAScript Harmony never referred to a specific edition of ECMA-262, nor could it. The Harmony name is used in nearby sub-fields of programming languages and software, e.g., the open source Java libraries developed under Apache auspices. FWIW, ES6 is a known thing, in view of sites such as http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/ (which goes to 7 ;-). Still, we can probably educate people and spread the word that ES6 = ECMAScript 2015, ES7 = ECMAScript 2016, etc. All under the Harmony umbrella, I trust. /be Arthur Stolyar wrote: Hi, I now version does not matter but implementation and features matter, why then you dropped the Harmony name? It was using for a while, then ES6 was using for a while, now you wants new name. Sounds weird. Argument about features does not work. ___ es-discuss mailing list es-discuss@mozilla.org mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JavaScript 2015?
That would be my preferred solution: the name affects book covers, domains, content, etc. = a significant amount of time and money. Even worse than renaming ES6 now would be renaming it later, though. On 23 Jan 2015, at 01:44, Arthur Stolyar nekr.fab...@gmail.com wrote: Can we leave ES6 to ES6 because it's already here and call ES7 -- ES2016? Since ES7 not here yet and there are not much mentions of it. 2015-01-23 2:39 GMT+02:00 Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org: Andrea Giammarchi wrote: I particularly don't like the idea that things could be dropped or rushed last minute just because the new years eve is coming ... this feel like those stories with tight deadlines where management could easily fail due over-expectations on all possible 3rd parts alignment ( you know, like those 12 different JS engines out there + spartans ) No last minute slips -- that's a schedule-chicken outcome (where the cars do not collide but one veers and drives off a cliff!). The new stuff has to board its release train or its champions and fans will be sad, and perhaps take a credibility hit. This doesn't mean larger work must be broken down into too many pieces, but that is a risk. Larger work that can track across multiple years is always risky -- in my experience it very often aims for a target near Alpha Centauri at sublight speed, when the real action was over at Tau Ceti due to an FTL breakthrough, but no one knew at first that (a) FTL was possible; or (b) the Centauri systems were uninhabitable. If you get what I mean ;-). (Spartan uses Chakra, last I heard.) Mature projects can do rapid-er release more easily than young ones, for sure. I recall 4.2BSD Unix, then 4.3, and a bit of 4.4. I do like the idea of having more frequent rolling releases, but yet I don't know why year-naming would be the choice. Does the name matter? You seemed to be objecting on more substantive grounds. Don't back off to mere quibbling about labels! Anyway, please consider keeping ES6 exactly ES6, we will have time to align the ESX where X = previous ESX +2009 concept. to Doctor Alex, at this point I think you should really stick with ES6 or avoid the ES at all and use JS 2015 This reminds me: Axel (not Alex) cannot recommend JavaScript 2015 to anything near the Ecma standard, because trademark. :-/ /be -- @nekrtemplar https://twitter.com/nekrtemplar -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: JavaScript 2015?
This reminds me: Axel (not Alex) cannot recommend JavaScript 2015 to anything near the Ecma standard, because trademark. :-/ Ah, good point. It’d be lovely if whoever owns the trademark now (Oracle?) could donate it to the community. Or the community buys it via crowd-funded money. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
JavaScript 2015?
I’m in the process of coming up with a good title for a book on ECMAScript 6. That begs the question: What is the best way to refer to ECMAScript 6? 1. The obvious choices: ECMAScript 6 or ES6. 2. Suggested by Allen [1]: JavaScript 2015. The advantage of #2 is that many people don’t know what ECMAScript 6 is. However, I’m worried that a book that has “2015” in its title will appear old in 2016. And the year scheme completely breaks with current tradition. I see two possibilities: * If there is a concerted effort to establish “JavaScript 2015” then I would support that and name my book accordingly. * Otherwise, JavaScript 6 is interesting: People who are aware of ECMAScript 6 will recognize it, but it will also mean something to people who don’t know what ECMAScript is. Is 2015, 2016, … really that much better than 6, 7, 8, … ? Would skipped years pose a problem for the former naming scheme? Axel [1] https://twitter.com/awbjs/status/558316031039381504 -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Question about Symbols and GlobalSymbolRegistry
Correct. The registry is only accessed via `Symbol.for(key)` and `Symbol.keyFor(sym)`. The parameter of `Symbol()` is a description, not a key. On 22 Jan 2015, at 01:36, Cyrus Najmabadi cyr...@microsoft.com wrote: Hi, I am reading the Symbol section of the ES6 spec (19.4), and my understanding is that calling the Symbol constructor does *not* add an entry to the GlobalSymbolRegistry. Is that correct? For example: var s1 = Symbol(“foo”); var s2 = Symbol.for(“foo”); In this example, s1 and s2 would be two distinct symbols. And in the following example: var s1 = Symbol(“foo”); var s2 = Symbol.keyFor(s1); In this example, s2 would be undefined. Am I understanding correctly? Thanks, Jason ___ es-discuss mailing list es-discuss@mozilla.org mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set.prototype.entries: indices as keys?
Sets are not a linear data structure, so the order of entries in a Set is irrelevant, unlike an Array whose elements must have an explicit position. Set entries in JS have an iteration order purely to match programmer intuition (and ensure that all implementations adhere), however there is no structural importance of the order. You can impose an order on the elements of a set, though. For example, Java’s `SortedSet` [1] has the methods `first()` and `last()`, which are occasionally useful. I agree that it feels weird to have indices attached to set elements, but it would at least make `entries()` useful. You could iterate and treat the first element and/or the last element differently. But the same can be achieved by iterating over a `zip()` of a set and a `range()` (assuming iterable-based tool functions `zip` and `range`). [1] http://docs.oracle.com/javase/7/docs/api/java/util/SortedSet.html -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Set.prototype.entries: indices as keys?
Currently the keys of the entries returned by `Set.prototype.entries()` are the same as the values: ```js let set = new Set(['a', 'b']); let pairs = [...set.entries()]; console.log(JSON.stringify(pairs)); // [[a,a],[b,b”]] ``` Given that sets are ordered, I’d use the “position” of an entry as the key: [[0,a],[1,b”]] Rationale: First, having an indices as keys makes the entries more useful. Second, destructuring already treats entries as if they had indices: ```js let [x,y] = set; // x='a'; y='b’; ``` -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Maps and sets and insertion order
I think it’s great that maps and sets honor insertion order. Two ideas: * Sets: Could the keys used for `Set.prototype.entries()` and `Set.prototype.forEach()` be the position of an element? IMO that’d be more useful than using the element as both key and value. * Maps: Long-term, I’d love to be able to access and delete entries by position. Axel -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Implicit coercion of Symbols
On 03 Jan 2015, at 19:52, Brendan Eich bren...@mozilla.org wrote:
None of the objects in the examples bz cited are Arrays -- what did you mean?
When I though of `+` being used inside square brackets, I only thought of
strings, not of numbers (first example).
In the first example, `this` is at least array-like. Otherwise, `slice`
wouldn’t work.
Axel Rauschmayer wrote:
Arrays are a good point, this is where I’d think accidental coercions are
most likely. The other use case is object-as-dictionary, which will slowly
be replaced by `Object.create(null)` (no need to escape in ES6+) and `Map`.
I don’t feel strongly either way, I just feel that the added spec complexity
is not ideal. Especially ToBoolean() not throwing an exception, while
ToString() and ToNumber() do.
On 03 Jan 2015, at 04:02, Boris Zbarsky bzbar...@mit.edu
mailto:bzbar...@mit.edu wrote:
On 1/2/15 9:40 PM, Axel Rauschmayer wrote:
Can you give an example?
get: function( num ) {
return num != null ?
// Return just the one element from the set
( num 0 ? this[ num + this.length ] : this[ num ] ) :
// Return all the elements in a clean array
slice.call( this );
},
That's from jQuery 2.1.3.
And from the same place:
function cache( key, value ) {
// Use (key + ) to avoid collision with native prototype properties (see
Issue #157)
if ( keys.push( key + ) Expr.cacheLength ) {
// Only keep the most recent entries
delete cache[ keys.shift() ];
}
return (cache[ key + ] = value);
}
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Implicit coercion of Symbols
Arrays are a good point, this is where I’d think accidental coercions are most
likely. The other use case is object-as-dictionary, which will slowly be
replaced by `Object.create(null)` (no need to escape in ES6+) and `Map`.
I don’t feel strongly either way, I just feel that the added spec complexity is
not ideal. Especially ToBoolean() not throwing an exception, while ToString()
and ToNumber() do.
On 03 Jan 2015, at 04:02, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/2/15 9:40 PM, Axel Rauschmayer wrote:
Can you give an example?
get: function( num ) {
return num != null ?
// Return just the one element from the set
( num 0 ? this[ num + this.length ] : this[ num ] ) :
// Return all the elements in a clean array
slice.call( this );
},
That's from jQuery 2.1.3.
And from the same place:
function cache( key, value ) {
// Use (key + ) to avoid collision with native prototype
properties (see Issue #157)
if ( keys.push( key + ) Expr.cacheLength ) {
// Only keep the most recent entries
delete cache[ keys.shift() ];
}
return (cache[ key + ] = value);
}
That's after looking through about 1/10 of the library. I'll bet there are
more. I'll also bet this sort of thing appears in every single major library
out there.
-Boris
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Implicit coercion of Symbols
Does it have to be a Reflect.* method? It could be `Symbol.prototype.getDescription()` or a getter. On 04 Jan 2015, at 02:25, Brendan Eich bren...@mozilla.org wrote: Rick Waldron wrote: That example above is pretty compelling for throw always consistency. With a new Reflect.* API for converting a symbol to its diagnostic/debugging string? If you agree, please file a bugs.ecmascript.org ticket. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Implicit coercion of Symbols
One reason it might make sense to throw, is people converting values to
string names for use as object properties. Reason you'd want to throw would
be to prevent accidentally making the key useless (different from its
original Symbol value).
This is exactly the reason.
Of course, having String(x) and '' + x diverge is funky, but not novel:
js o = {valueOf(){return 42}, toString(){return 'haha'}}
({valueOf:function valueOf(){return 42}, toString:function toString(){return
'haha'}})
js String(o)
haha
js ''+o
42
Playing devil’s advocate: How realistic a danger is this? Do people ever
compose a property key for an object out of several pieces?
It does add a fair amount of complexity for something that doesn’t seem that
common.
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
