Re: Implicit coercion of Symbols
Can you give an example? On 03 Jan 2015, at 03:34, Boris Zbarsky bzbar...@mit.edu wrote: On 1/2/15 9:33 PM, Axel Rauschmayer wrote: Do people ever compose a property key for an object out of several pieces? On the web? All the time. -Boris ___ 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
Throwing when symbol *wrappers* are converted to primitives
This is current V8 behavior:
```
let obj = {};
obj[Object(Symbol())] = true;
TypeError: Cannot convert object to primitive value
'' + Object(Symbol())
TypeError: Cannot convert a Symbol wrapper object to a primitive value
```
Both exceptions make a lot of sense, but I don’t see that in the spec. The way
I’d expect it to happen is via `Symbol.prototype[@@toPrimitive]` – it would
always throw. But that’s not the case.
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-symbol.prototype-@@toprimitive
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Throwing when symbol *wrappers* are converted to primitives
Interesting, thanks! Can you explain the rationale behind that decision? To me,
it seems like V8’s behavior is preferable – if I accidentally created instances
of `Symbol`, I would want to get errors as early as possible.
On 27 Dec 2014, at 08:41, Claude Pache claude.pa...@gmail.com wrote:
I guess that V8 follows an old version of the spec draft. That particular
behaviour was modified in Rev 28. See:
https://bugs.ecmascript.org/show_bug.cgi?id=3252
https://bugs.ecmascript.org/show_bug.cgi?id=3252
—Claude
Le 27 déc. 2014 à 08:17, Axel Rauschmayer a...@rauschma.de
mailto:a...@rauschma.de a écrit :
This is current V8 behavior:
```
let obj = {};
obj[Object(Symbol())] = true;
TypeError: Cannot convert object to primitive value
'' + Object(Symbol())
TypeError: Cannot convert a Symbol wrapper object to a primitive value
```
Both exceptions make a lot of sense, but I don’t see that in the spec. The
way I’d expect it to happen is via `Symbol.prototype[@@toPrimitive]` – it
would always throw. But that’s not the case.
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-symbol.prototype-@@toprimitive
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-symbol.prototype-@@toprimitive
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: classes and enumerability
The alternative is to treat enumerability the way ES6 treats holes: pretend it
doesn’t exist:
* Use `Reflect.ownKeys`, `Object.getOwnPropertyNames`,
`Object.getOwnPropertySymbols` instead of `Object.keys`.
* Don’t use the `for-in` loop (an easy one…)
* Change `Object.assign` so that it considers all properties, not just
enumerable ones.
* The properties of class prototypes remain non-enumerable.
* I’m unsure about new built-in instance prototypes. For consistency’s sake,
one may want to make them non-enumerable. But how would they be different from
a library?
Quoting Sebastian Markbåge:
https://twitter.com/sebmarkbage/status/547156703104753664
enumerable is just one of an infinite number of categories you might want
to filter on. It's a hack and should die.
Would this approach have any disadvantages?
On 24 Dec 2014, at 19:02, Kevin Smith zenpars...@gmail.com wrote:
```js
class List extends Array {
itsGoingToBeEnumerable() {
return 'but does it have to and would you expect to?';
}
}
```
That's a good point.
As far as I can tell, the downside risk associated with making class methods
non-enumerable centers around mixins:
- Legacy mixin utilities will tend to fail when given ES6 classes.
- We have no built-in function for doing proper mixins yet, and
`Object.assign` won't work at all.
I looked through my ES6 code and found a place where I was using
`Object.assign` as an simplistic mixin function. It might be a pain to have
to import a userland utility for such cases.
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: classes and enumerability
Got it, thanks! On 25 Dec 2014, at 01:26, Brendan Eich bren...@mozilla.org wrote: Axel Rauschmayer wrote: The alternative is to treat enumerability the way ES6 treats holes: pretend it doesn’t exist: That doesn't work, here or for holes. We've actually split APIs with respect to holes, and this will mean bugs. We did make an intentional future-trumps-past choice against holes, though. Here and on twitter, we seem to have members of the committee on both sides. Not good. Not saying consensus is broken and dissenters from the draft status will throw their bodies in front of the train, but it's worth extended discussion and (thanks again, Rick) measurement of what can be measured. * Use `Reflect.ownKeys`, `Object.getOwnPropertyNames`, `Object.getOwnPropertySymbols` instead of `Object.keys`. * Don’t use the `for-in` loop (an easy one…) * Change `Object.assign` so that it considers all properties, not just enumerable ones. * The properties of class prototypes remain non-enumerable. * I’m unsure about new built-in instance prototypes. For consistency’s sake, one may want to make them non-enumerable. But how would they be different from a library? Quoting Sebastian Markbåge: https://twitter.com/sebmarkbage/status/547156703104753664 enumerable is just one of an infinite number of categories you might want to filter on. It's a hack and should die. Would this approach have any disadvantages? The prescriptionist approach has not worked. See the Auburn study that Allen cited: http://munawarhafiz.com/research/jssurvey/GHB14-JSUsedParts.pdf People use for-in without hasOwnProperty -- a lot. Some intentionally well-used cases, no doubt -- others accidents waiting to happen. JS has some bad defaults, requiring long-winded workarounds. Lazy programmers will inevitably skip the workarounds. Let's not do another. /be -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Any news about the `module` element?
Is there any news about `module` element, any proposal I could follow to stay up to date? 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 would a 1JS-friendly strict mode look like?
That makes sense, yes. It’s great that we get this chance to clean up things in ECMAScript 6. On 16 Dec 2014, at 16:46, John Barton johnjbar...@google.com wrote: 1JS strict mode would look like modules. jjb -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
What would a 1JS-friendly strict mode look like?
Given 1JS – would strict mode have been done differently in hindsight? How? Thanks! Axel -- 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
Object.getPrototypeOf vs. Reflect.getPrototypeOf
Does the following rationale still stand? Source: https://mail.mozilla.org/pipermail/es-discuss/2013-June/030958.html * TVC: If we have `O.p.__proto__` do we want Object.setPrototypeOf or just Reflect.setPrototypeOf? * AWB: Makes sense to have Object.setPrototypeOf for consistency. * EA: Where do we draw the line (Object.x or Reflect.x)? * DH: People will need to be able to get this before we have a reflect module. * TVC: We need both because they have different return value (reflect setPrototypeOf returns boolean success value). It doesn’t seem like the question “where do we draw the line” has been answered satisfactorily. I’d drop `Object.setPrototypeOf` and only use `Reflect.setPrototypeOf` and `Reflect.getPrototypeOf`. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: 9.5.8 [[Get]] (P, Receiver)
Will do in a few days (the other one, too). Too busy ATM. On 30 Nov 2014, at 14:32 , Tom Van Cutsem tomvc...@gmail.com wrote: 2014-11-27 12:32 GMT+01:00 Axel Rauschmayer a...@rauschma.de mailto:a...@rauschma.de: Suggestion: mention in both cases that the property is an own property of the target. +1. It doesn't hurt to be too explicit in stating these invariants. It may help Allen if you can repost this as a bug in the ecmascript bug tracker: https://bugs.ecmascript.org/enter_bug.cgi?product=Draft%20for%206th%20Edition https://bugs.ecmascript.org/enter_bug.cgi?product=Draft%20for%206th%20Edition Cheers, Tom -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Default values of destructured arguments?
Already supported:
http://google.github.io/traceur-compiler/demo/repl.html#function%20foo%28{d}%3D{d%3A1}%29%20{%0A%20%20%0A}
http://google.github.io/traceur-compiler/demo/repl.html#function%20foo(%7Bd%7D=%7Bd:1%7D)%20%7B%0A%20%20%0A%7D
If you open a console, you can call `foo()`.
On 28 Nov 2014, at 16:45 , Bradley Meck bradley.m...@gmail.com wrote:
function foo({d}={d:1}) {
}
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Standard module API/specification?
The specification of these modules has been delayed, it won’t be in ES6. On 29 Nov 2014, at 7:38 , Isiah Meadows impinb...@gmail.com wrote: Where would I be able to find specifications on (proposed) standard modules such as @iter? Google isn't being my friend in finding these (except for @iter, which I knew where to look). -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
[[DefineOwnProperty]] (P, Desc)
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-proxy-object-internal-methods-and-internal-slots-defineownproperty-p-desc Quote (note typo in second item): 1. A property cannot be added as or modified to be non-configurable, if it does not exists as a non-configurable own property of the target object. 2. A property may not be non-configurable, if is corresponding configurable property of the target object exists. Question: Doesn’t #1 imply #2? -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
9.5.8 [[Get]] (P, Receiver)
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-proxy-object-internal-methods-and-internal-slots-get-p-receiver https://people.mozilla.org/~jorendorff/es6-draft.html#sec-proxy-object-internal-methods-and-internal-slots-get-p-receiver Quoting the spec (I’ve marked two typos): * The value reported for a property must be the same as the value of the corresponding target object property if the target object property is a non-writable, non-configurable data property. * The value reported for a property must be undefined if the corresponding corresponding [typo: mentioned twice] target object property is [typo: missing “a”] non-configurable accessor property that has undefined as its `[[Get]]` attribute. Suggestion: mention in both cases that the property is an own property of the target. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Is `List` really a specification type?
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-proxy-object-internal-methods-and-internal-slots-ownpropertykeys https://people.mozilla.org/~jorendorff/es6-draft.html#sec-proxy-object-internal-methods-and-internal-slots-ownpropertykeys The method `[[OwnPropertyKeys]] ( )` of proxy objects returns an actual `List` to JavaScript code. Does that make sense? I thought it was a specification(-only) type? How an instance is created is vague [1], which is appropriate for a data structure at the specification level, but not for one at the base level. `Array` seems like a better choice here. Or an iterator. [1] https://people.mozilla.org/~jorendorff/es6-draft.html#sec-createlistfromarraylike -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 spec: `export default` HoistableDeclaration
Interesting that that matters. I wouldn’t have thought so – given that modules
export references, not values.
On 20 Nov 2014, at 01:54, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Nov 19, 2014, at 4:42 PM, Axel Rauschmayer a...@rauschma.de wrote:
OK, I take it the following wasn’t viable?
that’s correct. We wanted the initialization of a function like:
export default function () {}
to be hoisted, just like:
export function f() {};
I suspect that that will confuse people: they will expect an anonymous
function to be an expression, not a declaration (even more so because the
operand of `export default` is usually an expression). Does hoisting even
matter if the function doesn’t have a name? Is it worth it to introduce a
completely new construct (an anonymous function declaration) just for
`export default`?
It can make a difference to circular modules that reference each other’s
default export. Hosted function iinitialization occurs before anything in
the module body is evaluated. export default expression isn’t initialized at
the point of the export declaration in the module body.
Allen
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Rationale for const not throwing in sloppy mode?
Given that `const` is a new feature – shouldn’t an exception be thrown in non-strict mode if a `const` variable is being changed? -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proxies as prototypes
On 23 Nov 2014, at 13:39, Till Schneidereit t...@tillschneidereit.net wrote: On Sun, Nov 23, 2014 at 11:58 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: Le 23/11/2014 07:41, Axel Rauschmayer a écrit : I’d expect the following code to log `GET bla`, but it currently doesn’t in Firefox. That’s because the Firefox implementation of proxies isn’t finished yet, right? Yes. That would be https://bugzilla.mozilla.org/show_bug.cgi?id=914314 https://bugzilla.mozilla.org/show_bug.cgi?id=914314 I think. Correct, that's a known bug. Jason and Eric (CC'd) are working on fixes to our MOP and Proxy implementation and I'd guess that this'll be fixed soon-ish. As pointed out in the bug, you can work around it by also implementing a [[Has]] handler. Thanks David and Till! I’ve only recently become fully aware of how much work that is, because proxies expose so much of the MOP (especially when it comes to getting and setting properties). With a proxy that logs when traps are triggered, you can see that auto-expansion in the Firefox console already triggers `ownKeys`, which is nice. I’m looking forward to `Reflect` being available in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=987514 https://bugzilla.mozilla.org/show_bug.cgi?id=987514 As you probably know, this is a polyfill: https://github.com/tvcutsem/harmony-reflect 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: Retrieving generator references
It just goes to show how good promises are for this kind of problem. I’d
probably promisify `readFile` and use `Q.spawn()`.
The best I could come up with for Node.js-style callbacks was the following
code.
```js
var fs = require(fs);
function *init() {
var nextFunc = yield;
var contents = yield fs.readFile(config.json, nextFunc);
doSomethingWith(contents);
console.log(Done);
}
var task = init();
task.next();
task.next(nextify(task));
function nextify(myTask) {
return function(error, result) {
if (error) {
myTask.throw(error);
} else {
myTask.next(result);
}
};
}
```
On 23 Nov 2014, at 01:55, Nicholas C. Zakas standa...@nczconsulting.com
wrote:
After playing around with generators for most of the day (and pretty much
loving all of it), I ended up with a code example for async that looks like
this:
```
var fs = require(fs);
var task;
function readConfigFile() {
fs.readFile(config.json, function(err, contents) {
if (err) {
task.throw(err);
} else {
task.next(contents);
}
});
}
function *init() {
var contents = yield readConfigFile();
doSomethingWith(contents);
console.log(Done);
}
task = init();
task.next();
```
The thing that immediately jumped out at me was how poorly the `task`
variable is being managed. So I was poking around trying to see if there was
a way to get a reference to the generator instance from within the generator
itself so I could pass it around, such as:
```
function *init() {
var contents = yield readConfigFile(this);
doSomethingWith(contents);
console.log(Done);
}
```
Of course, `this` isn't a reference to the generator itself, but rather the
this-binding for the function. It struck me, though, that my example could be
a lot cleaner if I could get a reference to the generator from the generator
function and pass that around rather than having to manage that reference
outside.
Now to my question: is there a way to get a reference to the generator from
inside the generator function?
(Also, sorry if I'm getting the nomenclature wrong, still trying to wrap my
head around the relationship between generators, iterators, and functions.)
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Retrieving generator references
As an aside, I still feel that two concerns are mixed in a generator function:
* The creation of the generator object. This is where the generator function is
like a constructor and where you’d expect `this` to refer to the generator
object.
* The behavior. This is where the generator function is like a real function.
A result of this mixing of concerns is that using `next()` to start a generator
feels slightly off and that the argument of that first `next()` invocation is
completely ignored.
Alas, I have no idea how to disentangle these concerns, but it would be nice if
we were able to.
On 23 Nov 2014, at 01:55, Nicholas C. Zakas standa...@nczconsulting.com
wrote:
After playing around with generators for most of the day (and pretty much
loving all of it), I ended up with a code example for async that looks like
this:
```
var fs = require(fs);
var task;
function readConfigFile() {
fs.readFile(config.json, function(err, contents) {
if (err) {
task.throw(err);
} else {
task.next(contents);
}
});
}
function *init() {
var contents = yield readConfigFile();
doSomethingWith(contents);
console.log(Done);
}
task = init();
task.next();
```
The thing that immediately jumped out at me was how poorly the `task`
variable is being managed. So I was poking around trying to see if there was
a way to get a reference to the generator instance from within the generator
itself so I could pass it around, such as:
```
function *init() {
var contents = yield readConfigFile(this);
doSomethingWith(contents);
console.log(Done);
}
```
Of course, `this` isn't a reference to the generator itself, but rather the
this-binding for the function. It struck me, though, that my example could be
a lot cleaner if I could get a reference to the generator from the generator
function and pass that around rather than having to manage that reference
outside.
Now to my question: is there a way to get a reference to the generator from
inside the generator function?
(Also, sorry if I'm getting the nomenclature wrong, still trying to wrap my
head around the relationship between generators, iterators, and functions.)
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Retrieving generator references
* The creation of the generator object. This is where the generator function is like a constructor and where you’d expect `this` to refer to the generator object. Nope, not a constructor (and if you don't call with 'new', what is 'this', pray tell?). I only mean it is “like a constructor” in that it is a function that, when invoked (in some way), returns a fresh object. The main purpose of a generator function is to specify the behavior of the generator object. But it also serves as its constructing entity. A double duty. * The behavior. This is where the generator function is like a real function. A result of this mixing of concerns is that using `next()` to start a generator feels slightly off and that the argument of that first `next()` invocation is completely ignored. We've discussed a special generator head form to declare that name, but not for ES6. For now it's Pythonic, except we decided not to throw if the initial .next call passes a non-undefined value. Alas, I have no idea how to disentangle these concerns, but it would be nice if we were able to. We're not changing generators at this point, but Nicholas's request for a way to reference the running generator-iterator instance is worth discussing more. It can't and shouldn't be 'this'. Does it violate POLA to provide (via another special form) for all generators? Users can provide their own bindings as noted, so is it a big problem? I’d pass the generator object reference to the generator function via `next()`, as the first step after creating the generator object. Not pretty, but relatively clean. I think the task.js reference, and ES7 async/await, point to a better direction: use helpers (libraries now, syntax soon) to automate harder and avoid the need for the me reference. I agree, I can’t think of a solution that wouldn’t be much too complicated for the minor problem that it solves. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Proxies as prototypes
I’d expect the following code to log `GET bla`, but it currently doesn’t in
Firefox. That’s because the Firefox implementation of proxies isn’t finished
yet, right?
```js
var proto = new Proxy({}, {
get: function(target, propertyKey, receiver) {
console.log('GET '+propertyKey);
return target[propertyKey];
}
});
var obj = Object.create(proto);
obj.bla;
```
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Map: filter/map and more
At the meeting it was decided not to go with `map` and `filter` sitting on
`Map.prototype`, but instead to use iterators in the way like:
```
map
.entries() // returns an iterator
.map((v, k, m) = { ... })
.filter((v, k, m) = { ... })
.collect(); // returns a new map after all transforms
```
Convenient, but this pattern couldn’t be extended to new Map classes or other
collections. I see two alternatives.
First, use the `Map` constructor. I don’t find this too bad and it’s
self-explanatory.
```js
new Map(map
.entries() // returns an iterator
.map((v, k, m) = { ... })
.filter((v, k, m) = { ... }));
```
Second:
```js
map
.entries() // returns an iterator
.map((v, k, m) = { ... })
.filter((v, k, m) = { ... })
.collectInto(new Map());
```
`collectInto(coll)` invokes `coll.set(k,v)` for each pair `[k,v]` in the
sequence. It returns `coll`.
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Map: filter/map and more
On 20 Nov 2014, at 1:49 , Dmitry Soshnikov dmitry.soshni...@gmail.com wrote:
(For the history of this thread to refer to it later)
At the meeting it was decided not to go with `map` and `filter` sitting on
`Map.prototype`, but instead to use iterators in the way like:
```
map
.entries() // returns an iterator
.map((v, k, m) = { ... })
.filter((v, k, m) = { ... })
.collect(); // returns a new map after all transforms
```
Question – shouldn’t this example be written as follows?
```
map
.entries() // returns an iterator
.map(([k,v], i, m) = { ... })
.filter(([k,v], i, m) = { ... })
.collect(); // returns a new map after all transforms
```
Otherwise, I suggest to change the names (e.g. to `mapPairs` and `filterPairs`).
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
ES6 spec: `export default` HoistableDeclaration
Quoting https://people.mozilla.org/~jorendorff/es6-draft.html#sec-exports `export default` HoistableDeclaration `export default` [lookahead ≠ `function`] AssignmentExpression `;` Questions: * Do these grammar rules mean that you have to put anonymous function expressions in parentheses? Is that desirable (given that it’s a frequent use case)? * If the purpose of the first rule is to enable default-exporting of declarations (= no semicolon) – shouldn’t classes be included? 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: ES6 spec: `export default` HoistableDeclaration
* Do these grammar rules mean that you have to put anonymous function
expressions in parentheses? Is that desirable (given that it’s a frequent
use case)?
No, HoistableDeclaration[Default] includes FunctionDeclaration that lacks a
BindingIdentifier.
OK, I take it the following wasn’t viable?
`export default` [lookahead ≠ `function (` ] HoistableDeclaration
`export default` AssignmentExpression `;`
* If the purpose of the first rule is to enable default-exporting of
declarations (= no semicolon) – shouldn’t classes be included?
It has nothing to do with semicolons. It's so a function that is a default
export can also have a local name binding.
Ah, interesting and useful.
We should also allow:
export default class Foo {};
where Foo is a module local binding.
Without the semicolon, though? The “operand” of `export default` is also a
declaration, right?
Please file a bug.
Will do, once I fully understand the issue.
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 spec: `export default` HoistableDeclaration
OK, I take it the following wasn’t viable?
that’s correct. We wanted the initialization of a function like:
export default function () {}
to be hoisted, just like:
export function f() {};
I suspect that that will confuse people: they will expect an anonymous function
to be an expression, not a declaration (even more so because the operand of
`export default` is usually an expression). Does hoisting even matter if the
function doesn’t have a name? Is it worth it to introduce a completely new
construct (an anonymous function declaration) just for `export default`?
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Array.isArray(new Proxy([], {})) should be false (Bug 1096753)
The subject is a SpiderMonkey bug. Is that really desirable? Doesn’t it invalidate the Proxy’s role as an interceptor? -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: async/await improvements
On 12 Nov 2014, at 16:33, James Long longs...@gmail.com wrote: Again, this is a generic issue for promises: a good solution there will fix everything. It's inherent in the promise design, there is no way to truly fix promises. You have to mark the end of a promise chain. It's always going to be that way. Is that true, though? Couldn’t a finalizer or something similar check (before a promise is garbage collected) whether all errors have been handled? -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Spec bug (proxies)? 9.5.8 [[Get]] (P, Receiver)
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-proxy-object-internal-methods-and-internal-slots-get-p-receiver https://people.mozilla.org/~jorendorff/es6-draft.html#sec-proxy-object-internal-methods-and-internal-slots-get-p-receiver To enforce the invariants, this operation uses `targetDesc`. That property descriptor is retrieved via target.[[GetOwnProperty]], which ignores inherited properties. Shouldn’t inherited properties be taken into consideration, 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: Spec bug (proxies)? 9.5.8 [[Get]] (P, Receiver)
OK. It surprised me, because `get` is so much about inheritance chains. I’ve not seen a rationale for the proxy invariants anywhere (including your technical report on proxies). Can I read up on it somewhere? In general, the proxy parts of the spec are very readable. Especially the summary of the invariants in each section on internal proxy properties is helpful. Thanks! Axel On 02 Nov 2014, at 20:42, Tom Van Cutsem tomvc...@gmail.com wrote: No, the proxy invariant checking mechanism never looks at inherited properties. Invariants related to frozenness (non-configurable, non-extensible) relate only to own properties. For example, even if an object is frozen, it may still inherit from a non-frozen object whose interface may change. And then there's `setPrototypeOf`, which may cause inherited properties to change altogether. Cheers, Tom 2014-11-02 19:25 GMT+01:00 Axel Rauschmayer a...@rauschma.de mailto:a...@rauschma.de: https://people.mozilla.org/~jorendorff/es6-draft.html#sec-proxy-object-internal-methods-and-internal-slots-get-p-receiver https://people.mozilla.org/~jorendorff/es6-draft.html#sec-proxy-object-internal-methods-and-internal-slots-get-p-receiver To enforce the invariants, this operation uses `targetDesc`. That property descriptor is retrieved via target.[[GetOwnProperty]], which ignores inherited properties. Shouldn’t inherited properties be taken into consideration, too? -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
CreateFromConstructor
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-createfromconstructor https://people.mozilla.org/~jorendorff/es6-draft.html#sec-createfromconstructor Isn’t the name of that operation misleading? How about the following changes? * Rename `CreateFromConstructor` to `CreateViaCreateAction`. * Throw an exception in step 3. CreateFromConstructor is only used in two locations: * 7.3.18 Construct (F, argumentsList) * Change step 2 so that `CreateViaCreateAction` is called if `F` has a property `[[CreateAction]]` and `OrdinaryCreateFromConstructor` otherwise. * 25.4.1.6 NewPromiseCapability ( C ) * `CreateFromConstructor` being used here effectively means that you must subclass `Promise` (the note sounds like that is desired). `CreatePromiseCapabilityRecord` re-implements the constructor protocol. I’d prefer it if that duplication of functionality didn’t happen and (e.g.) `Construct()` could be used, but that may be too complicated a change. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Types
TypeScript is about static type checking (and IDE support), what you want dynamic types that are better fits for problem domains. This is a step in that direction (in addition to typed arrays in ES6): https://github.com/dslomov-chromium/typed-objects-es7 https://github.com/dslomov-chromium/typed-objects-es7 On 31 Oct 2014, at 01:15, Zexx zex2...@gmail.com mailto:zex2...@gmail.com wrote: Hello, Isn't optional typing (similar to TypeScript) a good thing? Let's say I want to do some image processing. And images can be really huge nowadays. If I allocate an array of dynamic variables, that array may be 10x larger than if it was an array of bytes. And I need bytes to store and process R,G,B,A values separately. So, the array itself could have a descriptor of the type, and each member of the array can then contain only the value. As things are now, a 32 megapixel image in ES would allocate 32,000,000 x 4 = 128 million dynamic variables. If each variant takes up 8 bytes, that's 1 GB per image. Let's say I have two source images, one mask and one output. That's 4 gigabytes just in images, not counting the application, libraries, web browser, other running apps, OS, drivers, etc. That's a waste of resources. Native apps would need only about 0.5 GB for all 4 source images, so it would run on a wide variety of devices as opposed to the ES variant. And thus the author would sell more copies and earn more money. Instead of getting comments like Why did you made this crappy slow app. Learn to program. Competition is much faster. If ES is to become a proper, truly versatile language, shouldn't programmer be allowed to use it's knowledge of the app design to optimize resources? Best regards, Zex ___ es-discuss mailing list es-discuss@mozilla.org mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- 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: Current module path
This is the most recent information on module meta-data: https://esdiscuss.org/topic/es6-module-syntax-done On 24 Oct 2014, at 00:27, Maël Nison nison.m...@gmail.com wrote: I haven't seen module.name http://module.name/ / module.address in the latest draft, have they been discussed? -- 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 makes a file a module?
It depends on how you access it: if you import the file or load it via `module` then the file is interpreted as a module. On Oct 19, 2014, at 19:50 , Mark Volkmann r.mark.volkm...@gmail.com wrote: I understand that module code is implicitly in strict mode. In an ES6 environment, what causes a .js file to be treated as a module? Does that happen automatically to all files that export at least one thing? -- R. Mark Volkmann Object Computing, Inc. ___ 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: Errors in incorrect number literals
According to 11.8.3, you'll get a syntax error – they won't even be parsed, because they are not syntactically legal. [[[Sent from a mobile device. Please forgive brevity and typos.]]] Dr. Axel Rauschmayer a...@rauschma.de http://rauschma.de On 15.10.2014, at 10:18, Den Tuzhik dentuz...@gmail.com wrote: Right, it was a typo. Consider `0xFW`. Nevertheless the question remains, what kind of error will such cases produce? Denis. On Wed, Oct 15, 2014 at 2:10 AM, Brendan Eich bren...@mozilla.org wrote: Caitlin Potter wrote: I’m not sure what the problem with `0xFE` is supposed to be, though? Right, 0xFE is a fine hex literal. One must remember all the punning uses of hex: 0xFEEDFACE, 0xFEEDBABE, 0xCAFE, etc. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set API
Are we OK with this? Seems like removing `entries`, `keys` and providing own default `@@iterator` for `Set` which should be just `values()` would make it more sense from the abstraction usage perspective. W.r.t. your last suggestion: that’s how the spec does it. Anything else would definitely not have made sense. https://people.mozilla.org/~jorendorff/es6-draft.html#sec-set.prototype-@@iterator -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
`throw` as an expression?
Use case: With promises, the expression body form of arrow functions is so convenient. Alas, `throw` being a statement, you can’t use it there. For example, the following code is not syntactically legal: ```js asyncFunc() .then(count = count = 0 ? count : throw new Error(...)) .then(...) .catch(...); ``` Could `throw` be turned into an expression? -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Promise.resolve() and jQuery deferreds
AFAICT, `Promise.resolve()` is enough to convert jQuery deferreds to the ES6 API. Correct? 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: Map: filter/map and more
Then thing is: if we'd like to use maps for such use-case, it brings us back
to that inconvenient imperative style of assignments (even worse, since you
have to repeat that `.set(...)` constantly):
```
var requestData = new Map();
requestData.set(Names.ID, id);
requestData.set(Names.EMAIL, email);
requestData.set('needsReload', id);
...
```
Note that you can chain:
```js
var requestData = new Map()
.set(Names.ID, id)
.set(Names.EMAIL, email)
.set('needsReload', id);
```
Not too bad, IMO.
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Map: filter/map and more
Ah, thanks! Then I’d wrap the result of `entries()` in `Array.from()`. In ES7, we’ll hopefully be able to use comprehensions or iterator helper functions. On Oct 1, 2014, at 22:27 , Rick Waldron waldron.r...@gmail.com wrote: On Wed, Oct 1, 2014 at 4:17 PM, Axel Rauschmayer a...@rauschma.de wrote: On Oct 1, 2014, at 22:12 , Axel Rauschmayer a...@rauschma.de wrote: 1. Transforming iteration methods We're currently polyfillying the `Map`, and got some questions form devs. One of them is about transforming iteration methods, like `map` and `filter`. Unfortunately I missed that part of the spec when it was approved, so can someone please remind/clarify -- was it an intended decision not to hap Map#map, Map#filter? I can see only Map#forEach in the spec. Are maps immutable? -- That's fine, the `map` and `filter` return a new map. FWIW: I’ll probably use the following work-arounds. I don’t expect performance to be an issue for my applications; it’d be interesting to hear if it becomes a problem for someone. ```js let map2 = new Map(map1.entries().filter((key, value) = key = 0)); let map2 = new Map(map1.entries().map((key, value) = [key * 2, value * 2])); entries() returns an iterator, not an array. Rick -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Map: filter/map and more
We could definitely have Map and Set literals:
const map = {1 = one, two = true, false = three};
Would that be tricky to parse if keys can be arbitrary expressions (incl. array
literals)?
const set = {1, two, false};
If you still buy Harmony of My Dreams, prefix # before { to get immutable
value-type forms.
I don't mind reusing = in initialiser context where : would go, but perhaps
someone sees a problem I don't.
Using something other than a colon seems a good idea, to make it clear that any
kind of value can be used as keys.
Another possibility:
```js
const map = {: 1 = one, two = true, false = three :};
const set = {. 1, two, false .};
```
--
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.arguments in JSC
Out of historical curiosity: was `Function.arguments` ever useful for anything? Why not simply use `arguments`? On Sep 28, 2014, at 6:51 , John Lenz concavel...@gmail.com wrote: I took a look at Google's internal code index for reference to Function.prototype.arguments and turned up many references to it (PhpMyAdmin, some Intel benchmark, some internal code, etc). This is only code used internally at Google (or was at one time) and not by any means an index of the entire web, but it does use the Closure Compiler and type information to accurately find references. These are not just simply references to an arguments property but are references to the arguments property off of objects know to be functions.These references roughly (from my quick perusal), were about 50% were V8 or similar unit tests, 25% references that could be trivially replaced with a reference to the active function's arguments variable, and 25% were doing something tricky (Function.caller.arguments, someevent.handler.arguments). I'm sure you didn't expect that there would be zero breakage, but I wanted to give you a heads up that there might be more than you expect. On Sat, Sep 27, 2014 at 11:38 AM, Oliver Hunt oli...@apple.com wrote: Hi all, as a heads up we’re going to be doing an experiment in our tree to see if we can kill off the function.arguments property entirely. We’re super hopeful we can make it go away safely, and we’ll post a follow up when we have some actual information about what happens. If you’re interested in following directly you can track the bug: http://webkit.org/b/137167 —Oliver -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
ES6 promises: [[AlreadyResolved]] – needed?
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-createresolvingfunctions Each resolving function R uses R.[[AlreadyResolved]].[[value]] to prevent the same promise from being resolved twice. Question: Couldn’t R.[[Promise]].[[PromiseState]] be used, instead? -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ES6 promises: [[AlreadyResolved]] – needed?
Figured it out: This is needed for “locking in”. Quoting [1]: A promise is _resolved_ if it is settled or if it has been locked in to match the state of another promise. Attempting to resolve or reject a resolved promise has no effect. [1] https://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise-objects On Sep 25, 2014, at 6:49 , Axel Rauschmayer a...@rauschma.de wrote: https://people.mozilla.org/~jorendorff/es6-draft.html#sec-createresolvingfunctions Each resolving function R uses R.[[AlreadyResolved]].[[value]] to prevent the same promise from being resolved twice. Question: Couldn’t R.[[Promise]].[[PromiseState]] be used, instead? -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: new instantiation design alternatives
I find the new suggestions hard to make sense of and the current approach quite elegant: ``` Foo[[Construct]](arg) ::= 1. let obj = Foo[@@create]() 2. Foo.call(obj, arg) ``` To me, it seems that this is how things should work internally, because that’s what’s actually going on. Is there no other way to fix the following two problems? For example: to fix #2, couldn’t we somehow prevent direct invocations? I also don’t fully understand what #1 means. 1. If instances aren't sufficiently initialized by @@create, then instance objects could leak (e.g. via a nefarious decoupling between the @@create allocation process and the constructor-function initialization process) 2. @@create could be called directly Observation about the new approach:: could the `if (new^) ...` check be turned into a method? Axel On 11 Sep 2014, at 18:35 , Allen Wirfs-Brock al...@wirfs-brock.com wrote: At the last TC39 meeting ( https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-07/jul-30.md#44-instantiation-reform-review-create-design-rationale-and-possible-alternatives and https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-07/jul-31.md#44-follow-up-instantiation-reform-create ) we agreed to a general direction to try for a new object instantiation design to replace @@create. Since then I have gotten feedback and had design discussions with a number of individuals. This has lead to a number of refinements of the core design and one remaining point where there are strong contrary positions. The point of contention is about whether or not a subclass construction ever implicitly calls its superclass constructor. https://gist.github.com/allenwb/291035fbf910eab8e9a6 summaries the main syntactic changes since the meeting and provides rationales them. These features are common to both alternates. this is a good place to start, after reading the meeting notes. I have prepared two longer Gists that outline the two alternatives designs, presents design rationales, and provides usage examples for a number of likely use cases. Note that there is more commonalities then differences among the two alternatives. the syntactic choices and semantics of [[Construct]] are the same for both. These two Gist have parallel construction for easy comparison. I suggest approaching this is by first readying through one of the Gists and then doing a side by side read through of the alternative to see the differences in the designs and usage. https://gist.github.com/allenwb/5160d109e33db8253b62 with implicit super construct if no local allocation https://gist.github.com/allenwb/53927e46b31564168a1d explicit super construct required if no local allocation I appreciate it if major constructive feedback on any of these documents were made via Gist comments. 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: ... A community is writing the spec...
As previously announced here, the current schedule is to be finished by the end of the year, to start the publication process in March 2014 and to have a standard by June 2014. They already happened. Did you mean 2015? Yes I did! -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: import script -- .esm
Modules and scripts can not always be identified by inspection. Consider: foo.js --- const answer = 42; --- The semantics of this are quite different depending upon whether foo.js is evaluated as a script or loaded as a module. Given that module files and script files have different semantics, I would definitely want different file endings for them – for both humans and machines. 1JS doesn’t apply here. 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: [revise] ... A community is writing the spec...
it) for July 2015 with, for example, for-of, iterators, generators, comprehensions (it's all related, so in a single set) and if possible, classes and/or promises; ... etc. Possibly switching to 6 when something big gets in (symbols, classes, proxies). This would be nice. Really nice. To all of us who want to get ES.next and actually start developing in it. Thanks, Herby ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss Mail Attachment.txt___ 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: ... A community is writing the spec...
Now is second half of 2014, and lots of issues are not closed yet, from what I see. The spec already looks pretty complete to me and Traceur and TypeScript do a pretty good job of letting you use ES6 today. As previously announced here, the current schedule is to be finished by the end of the year, to start the publication process in March 2014 and to have a standard by June 2014. I got delusioned as well. Isn't the model of big new editions of spec over; in the times we live now, with two-week frequent releases? I think ES6 will never see the light when taken from this approach. That's why, shouldn't the release policy be changed so that: It has already changed, but not for ES6. ECMAScript 7 and later will have fixed release dates. Only features that are ready at a given date will be included. Background: https://github.com/tc39/ecma262 -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: use strict VS setTimeout
On Sep 7, 2014, at 19:47 , Mark S. Miller erig...@google.com wrote: On Sun, Sep 7, 2014 at 10:36 AM, Mathias Bynens mathi...@opera.com wrote: On Sun, Sep 7, 2014 at 7:29 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: This looks like a potential problem when possible passed methods are not bound + it looks inconsistent with *use strict* expectations. Yes. This looks like a typical screwup. Thanks for pointing it out. Interesting. Follow-up question: isn’t strictness propagated lexically? That is, shouldn’t the parameter of `setTimeout()` be strict even without being explicitly declared as such? -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `this` inside modules
The latest info from Domenic is:
```js
import { name, url } from this module;
```
Source: http://esdiscuss.org/topic/es6-module-syntax-done
On 28 Aug 2014, at 20:19 , Rick Waldron waldron.r...@gmail.com wrote:
On Thu, Aug 28, 2014 at 2:17 PM, Matthew Robb matthewwr...@gmail.com wrote:
From my interpretation of the last face to face notes and the breakout
session it would appear as if instead you will be able to `import mod from
this`
Can you link to the reference?
Rick
- Matthew Robb
On Thu, Aug 28, 2014 at 12:26 PM, John Barton johnjbar...@google.com wrote:
Was this decision reversed? I don't see Reflect.global in the new spec.
online.
jjb
On Mon, Jun 9, 2014 at 10:08 AM, Caridy Patino car...@gmail.com wrote:
My point: if 'this' is not global in modules, then ES6 must have an
alternative way to name the global object.
Yes, we covered that last week. `Reflect.global` seems like the right place
for it considering that it will be defined per realm.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
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
Promise() vs. new Promise()
Currently there seem to be two ways to create promises. Normal classes throw an exception if you call them as functions (without `new`). Should `Promise` do the same? 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: Promise() vs. new Promise()
Ah, true. Cool, thanks. On Aug 20, 2014, at 15:23 , Rick Waldron waldron.r...@gmail.com wrote: On Wed, Aug 20, 2014 at 8:52 AM, Axel Rauschmayer a...@rauschma.de wrote: Currently there seem to be two ways to create promises. Normal classes throw an exception if you call them as functions (without `new`). Should `Promise` do the same? They already do: https://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise Steps 1-4. Rick -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: That First Next Argument
Isn’t the problem that a generator function contains the code for both
generator object creation and generator behavior? Normally, this is convenient,
because both parts can share an environment. But for Kevin’s use case, it
becomes a problem.
One possibility may be to implement this as a tool class, separating the
concerns “construction” and “behavior”:
```js
class MyGenerator extends CustomGenerator {
constructor(/* args for generator object creation */) {
super();
...
}
* behavior(firstArgOfNext) {
...
}
}
```
On Aug 20, 2014, at 18:43 , Brendan Eich bren...@mozilla.org wrote:
Andy Wingo wrote:
On Wed 20 Aug 2014 16:41, Kevin Smithzenpars...@gmail.com writes:
I'm still curious why we need to go through such exercises, though. It
seems clear to me that this is a weakness of the current design, and
would be easily addressed with syntax. Is there a back-story that I'm
not aware of?
No backstory that I'm aware of -- only something that doesn't really
fall out from the generators design. There's just no sensible name you
could give the value (without getting creative with lexical scope),
and no continuation waiting to receive it.
Right. Anyone know whether this has come up as a PEP or suggestion on
python-dev?
The meeting notes Kevin cited in the thread root don't mention it, but IIRC
we did briefly talk about syntax that could be added in a future edition (AKA
next year in a spec, next month in a browser implementation) for receiving
that first-next value:
function* gen(a, b, c) first {
...
}
Not bikeshedding, some found it ugly or too terse, many wondered about other
future syntax vying to go after the parameter list. But the idea seems good.
/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
Thread about ES6 on reddit
http://www.reddit.com/r/javascript/comments/2d4wed/can_you_explain_to_me_something_about_es6/ This should please people worried about ES6 being perceived negatively: the tone in this thread is quite upbeat. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Referencing `super`
On 06 Aug 2014, at 21:03 , Brendan Eich bren...@mozilla.org wrote:
Rick Waldron wrote:
I'm cool with super() in methods, I forgot we disallowed naked
`super`, and my gut says we would support it as equivalent to `this`.
To clarify, you don't mean `super === this`, right?
The alternative is for bare `super` to denote the same-named superclass
method bound to `this`. That enables the equivalence Allen wrote based on
Brett's error citation:
let superSubmit2 = super; // Error: Unexpected token ;
superSubmit2(); // if no Error, this is equivalent to super()
But that breaks the other equivalence:
super.method(); do { let s = super; s.method(); }
So you can see why bare `super` is currently illegal! (Want a better error
message than the one Brett showed.)
If we make bare `super` an error for now, in hopes of resolving this conflict
of equivalences later, which way do we think we'll resolve? We ought to have
an opinion now.
Given how much `super` does under the hood (if you call a method, you get a
super/this hybrid), a stand-alone `super` may give people the wrong idea (and I
don’t see how it would be useful). It may be better to provide access to
[[HomeObject]] (via Reflect?).
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Loader vs ES6 Classes
A good point (independently of classes): why change the value of `this`?
On Aug 3, 2014, at 20:19 , John Barton johnjbar...@google.com wrote:
Since I guess not too many developers work with ES6 and the Loader object,
here is some feedback: the Loader callback design does not play well with ES6
classes.
The Loader takes 'options', an object with function properties like
normalize, locate, and fetch. If you pass a literal object with function
properties, it works fine.
If you pass an instance of a class, then you discover that the Loader calls
these functions with 'this' bound to the Loader, not the 'options' object.
There isn't a simple way around this as far as I know. The options functions
don't have access to the options object, only module-state and global. So
you're stuck with the awkward:
var loader = new Loader({
normalize: options.normalize.bind(options),
locate: options.locate.bind(locate),
etc,
};
I guess you can give up on ES6 inheritance and create the hook instances by
old-school JS, but that is even more annoying. Or maybe there is something
else I've not thought of?
jjb
___
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: Loader vs ES6 Classes
On Aug 4, 2014, at 15:16 , Juan Ignacio Dopazo jdop...@yahoo-inc.com wrote:
In practice we've found that we rarely use the new Loader(hooks)` option and
instead this is more common:
var loader = new Loader();
var loaderFetch = loader.fetch.bind(loader);
loader.fetch = function (loadRecord) {
// do something
return loaderFetch(loadRecord);
};
Why not like this then? You’d need (a compiler for) ES6, though.
```js
class MyLoader extends Loader {
fetch(loadRecord) {
// do something
return super(loadRecord);
}
}
let loader = new MyLoader();
```
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Loader vs ES6 Classes
On Aug 4, 2014, at 16:33 , John Barton johnjbar...@google.com wrote:
As far as I can tell you are basically arguing that simple Loader hooks don't
need object state. Of course that is true.
No, I’m arguing that Juan’s code is basically “subclassing” a loader,
overriding a method and calling that method. ES6 classes seem like a more
elegant way of doing this. You’d get as much object state in the subclass as
you want.
And sure we can write code that carefully and cleverly avoids using 'this'.
Why? ES6 added classes because this is often the clearest way to structure
more complex systems.
In my case the LoaderHooks.normalize() function needs to mark names as
originating from 'script' rather than 'module' based on the name (eg
'script:' or in my case trailing ',script'. The marking table needs to be on
'this'.
I extend LoaderHooks to InterceptOuputLoaderHooks which calls
this.onTranscoded() to copy the transcoded results from load to listeners.
But my real point is why should I have to think about 'this' binding in 2015?
We don't need to use an old school API now, we have ES6.
jjb
On Mon, Aug 4, 2014 at 6:29 AM, Axel Rauschmayer a...@rauschma.de wrote:
On Aug 4, 2014, at 15:16 , Juan Ignacio Dopazo jdop...@yahoo-inc.com wrote:
In practice we've found that we rarely use the new Loader(hooks)` option
and instead this is more common:
var loader = new Loader();
var loaderFetch = loader.fetch.bind(loader);
loader.fetch = function (loadRecord) {
// do something
return loaderFetch(loadRecord);
};
Why not like this then? You’d need (a compiler for) ES6, though.
```js
class MyLoader extends Loader {
fetch(loadRecord) {
// do something
return super(loadRecord);
}
}
let loader = new MyLoader();
```
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Loader vs ES6 Classes
We seem to have a different understanding of “object state”. What do you mean
by that term?
On Aug 4, 2014, at 17:30 , John Barton johnjbar...@google.com wrote:
Neither example binds 'this' assuming the current Loader implementation, so
no object state. Although maybe you are saying your example ought to work,
then we agree ;-)
On Mon, Aug 4, 2014 at 7:47 AM, Axel Rauschmayer a...@rauschma.de wrote:
On Aug 4, 2014, at 16:33 , John Barton johnjbar...@google.com wrote:
As far as I can tell you are basically arguing that simple Loader hooks
don't need object state. Of course that is true.
No, I’m arguing that Juan’s code is basically “subclassing” a loader,
overriding a method and calling that method. ES6 classes seem like a more
elegant way of doing this. You’d get as much object state in the subclass as
you want.
And sure we can write code that carefully and cleverly avoids using 'this'.
Why? ES6 added classes because this is often the clearest way to structure
more complex systems.
In my case the LoaderHooks.normalize() function needs to mark names as
originating from 'script' rather than 'module' based on the name (eg
'script:' or in my case trailing ',script'. The marking table needs to be
on 'this'.
I extend LoaderHooks to InterceptOuputLoaderHooks which calls
this.onTranscoded() to copy the transcoded results from load to listeners.
But my real point is why should I have to think about 'this' binding in 2015?
We don't need to use an old school API now, we have ES6.
jjb
On Mon, Aug 4, 2014 at 6:29 AM, Axel Rauschmayer a...@rauschma.de wrote:
On Aug 4, 2014, at 15:16 , Juan Ignacio Dopazo jdop...@yahoo-inc.com wrote:
In practice we've found that we rarely use the new Loader(hooks)` option
and instead this is more common:
var loader = new Loader();
var loaderFetch = loader.fetch.bind(loader);
loader.fetch = function (loadRecord) {
// do something
return loaderFetch(loadRecord);
};
Why not like this then? You’d need (a compiler for) ES6, though.
```js
class MyLoader extends Loader {
fetch(loadRecord) {
// do something
return super(loadRecord);
}
}
let loader = new MyLoader();
```
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
for-of in Firefox
Does Firefox not yet do the one binding per loop iteration? I would have
expected the output `0` in the following code.
```js
let arr = [];
for (let i of [0, 1, 2]) {
arr.push(() = i);
}
console.log(arr[0]()); // 2
```
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Reflect.hasOwn() ?
Overall, I'm leaning towards keeping the built-in Reflect API minimal. There's room for many more utility methods (Reflect.getPropertyDescriptors comes to mind) which can all be expressed as a library. After thinking about it some more, I agree w.r.t. these two examples: * As far as I can tell, `hasOwnProperty` is mainly used to implement maps via objects. `Map` will eliminate this use case. * `getPropertyDescriptors` is useful for cloning objects via `Object.create()`, where `Object.assign` can often be used in ES6. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Reflect.hasOwn() ?
On Jul 26, 2014, at 20:36 , Kevin Smith zenpars...@gmail.com wrote: * As far as I can tell, `hasOwnProperty` is mainly used to implement maps via objects. `Map` will eliminate this use case. To a certain extent yes, but not completely. Objects-as-maps will still be used quite frequently as object literals passed into functions (as an options object, for example). I think that there is still a need here. Yes, but it’s much less urgent. Since we are really interested in *keys*, what about this: Object.hasKey(obj, someKey); Ah, good point! I hadn’t thought of symbols as property keys. which would be a more ergonomic and efficient way of saying: Object.keys(obj).some(key = key === someKey) Did you mean `Reflect.ownKeys()`? How about: ```js Reflect.ownKeys(obj).indexOf(someKey) = 0 ``` Or, maybe in ES7: ```js Reflect.ownKeys(obj).contains(someKey) ``` -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Reflect.hasOwn() ?
ECMAScript 6 mostly eliminates the need to call methods generically (no need to
use the array-like `arguments`, `Array.from()`, spread operator, etc.).
The only exception that comes to my mind is `{}.hasOwnProperty.call(obj, key)`
(which is the only safe way to invoke this method). Would it make sense to
provide that as a tool function, e.g. as `Reflect.hasOwn()`?
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Reflect.hasOwn() ?
On Jul 26, 2014, at 6:02 , Peter van der Zee e...@qfox.nl wrote:
On Sat, Jul 26, 2014 at 5:43 AM, Axel Rauschmayer a...@rauschma.de wrote:
The only exception that comes to my mind is `{}.hasOwnProperty.call(obj,
key)` (which is the only safe way to invoke this method). Would it make
sense to provide that as a tool function, e.g. as `Reflect.hasOwn()`?
That would make it unsafe again. Not so much from random people
polluting the global Object, but certainly unsafe from a security
perspective.
With “safe”, I only meant w.r.t. overriding (e.g., `obj.hasOwnProperty('foo')`
fails if `obj` has an own property whose name is `'hasOwnProperty'`).
Security-wise, how is `{}.hasOwnProperty.call()` safer than a hypothetical
`Reflect.hasOwn()`?
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: RegExp spec question
Yes, the /g flag is confusing, because the regular expression kind of turns into an iterator. I’d much prefer an actual iterator-based API that doesn’t mutate the regular expression. On Jul 16, 2014, at 9:26 , Alex Vincent ajvinc...@gmail.com wrote: r = /\u0020+$/g; p = r.exec( ); q = r.exec( ); JSON.stringify([p, q]) // [[\ \],null] Why does calling exec the second time generate null? When I try the regular expression without the /g flag, I get: // [[\ \],[\ \]] -- The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own. -- Alexander J. Vincent, June 30, 2001 ___ 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: 25.4.1.3 CreateResolvingFunctions ( promise )
Got it, thanks! On Jul 12, 2014, at 6:14 , Domenic Denicola dome...@domenicdenicola.com wrote: Resolving does not imply settling. For example, resolving with a forever-pending promise. Rejecting is a subset of resolving, by resolving with a rejected promise. From: Axel Rauschmayer Sent: 2014-07-11 20:50 To: es-discuss list Subject: 25.4.1.3 CreateResolvingFunctions ( promise ) Wouldn’t `CreateSettlingFunctions` be a better name than `CreateResolvingFunctions` (or a similar term that is a generalization of “rejecting” and “resolving”)? Axel -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
25.4.1.3 CreateResolvingFunctions ( promise )
Wouldn’t `CreateSettlingFunctions` be a better name than `CreateResolvingFunctions` (or a similar term that is a generalization of “rejecting” and “resolving”)? 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: Specifying template strings
On Jul 9, 2014, at 21:41 , Rick Waldron waldron.r...@gmail.com wrote: On Wed, Jul 9, 2014 at 11:25 AM, Axel Rauschmayer a...@rauschma.de wrote: I find the specification of template strings still a bit difficult to understand: – The abbreviations TV and CV are used 12.2.9, but defined in 11.8.6.1. Did you mean TV and TRV? This is no different than: - String SV and CV - Number MV Which are all defined in Chapter 11 Yes, I meant TV and TRV. I’d prefer these names to be longer. The short names are not very self-explanatory and finding their definitions is difficult, too (different chapter!). 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: Specifying template strings
– Tagged templates are explained via EvaluateCall(tagRef, TemplateLiteral, tailCall). I think it would be easier to understand if it used GetTemplateCallSite. Because a Tagged Template is a call. Would it be clearer if there was a note that highlighted the fact that the actual TemplateLiteral provides the argument list for the call? Yes. Naively, I’d expect the result of a TemplateLiteral to be a string. But I previously didn’t understand the difference between static semantics and runtime semantics. The indirection makes things more difficult to follow, but I assume it helps with writing the specification (given proxies, generators etc.). 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: Specifying template strings
Yes. Naively, I’d expect the result of a TemplateLiteral to be a string. But I previously didn’t understand the difference between static semantics and runtime semantics. The indirection makes things more difficult to follow, but I assume it helps with writing the specification (given proxies, generators etc.). Static semantics is about things about or which can be derived from just the source code, independent of the actual execution of the code Runtime semantics is about what actually happens when the program executes and typically has dependency upon the runtime state of the program. Yes. It’s quite clever how this attaches behavior to grammar rules (which initially confused me – I’m more used to runtime semantics referring directly to syntax). It seems to me that part of the challenge of writing and reading the spec is that it has the complexity and structure of code, but without the support of code-focused tools such as IDEs. In an IDE, I’d simply click on an identifier to jump to its definition. Refactoring would also be simple(r). -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Specifying template strings
I find the specification of template strings still a bit difficult to understand: – The abbreviations TV and CV are used 12.2.9, but defined in 11.8.6.1. – Tagged templates are explained via EvaluateCall(tagRef, TemplateLiteral, tailCall). I think it would be easier to understand if it used GetTemplateCallSite. – It’d be nice if untagged template strings and tagged templates could be mentioned closer together. They are basically the same thing and this structure seems to be dictated by grammar. To me, template strings are more like tagged templates without a tag. Would it make sense to specify them that way? Axel -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Default exports, without explicit syntactic support
(I’m happy with David’s proposal, but I’d like to try bikeshedding one more
time.)
Building on an idea by Kevin Smith: how about supporting default exports
without any explicit syntactic constructs? The convention would be: the name
`_` is used for default exports. The following is a single-export module.
```js
// lib/MyClass.js - alternative A
export const _ = class {
...
};
// lib/MyClass.js - alternative B
export class _ {
...
}
// main.js
import { _ as MyClass } from lib/MyClass;
```
Importing a multi-export module:
```js
import fs from fs;
fs.renameSync('foo.txt', 'bar.txt');
```
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Default exports, without explicit syntactic support
// my-class.js
export class MyClass {
constructor() { ... }
method() { ... }
}
// use-class.js
import { MyClass } from my-class.js;
You do have redundancy in `my-class.js` and, as Marius pointed out, the
importer has to know both the name of the module and the name of the entity
inside the module. Not that big of a deal. Again, standardizing on `_` for
default exports helps, but then importing is more verbose:
// my-class.js
export class _ {
constructor() { ... }
method() { ... }
}
// use-class.js
import { _ as MyClass } from my-class.js;
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A way of explicitly reporting exceptions
[...] Finally, it hasn't been discussed much, but some platforms provide explicit access to the 'uncaughtException' handler. +1. This feature would be a complement to what bz proposed. Either feature could be added and used independently from the other. I’m not completely sure, but Angular’s work on Zones may apply here, too, to configure when and what to catch: https://github.com/angular/zone.js -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Module Default Export Syntax
I do like the conciseness of the last form. The other forms do indeed not seem
very useful.
On Jun 25, 2014, at 5:45 , Kevin Smith zenpars...@gmail.com wrote:
ExportDeclaration:
...
export default ClassDeclaration
export default FunctionDeclaration
export default GeneratorDeclaration
export default = AssignmentExpression
To reply to myself (since no one else appears to be interested), I think it
might even be best to drop these special forms altogether. The non-sugared
form of:
export { someVar as default };
is already very concise, and will help developers understand what this whole
default thing is about. The sugar appears to be obfuscating the design,
and is doing more harm than good.
Again, thoughts?
___
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: ModuleImport
On Jun 20, 2014, at 11:36 , Sébastien Cevey seb.ce...@guardian.co.uk wrote: Reading Marius' email, I realised what I find confusing in the newly proposed syntax that uses `*' to import the default export. The `*' symbol universally represents a glob of everything, but when used to import from a module that has multiple exports, you won't get everything, you will get either the single default export (if there is one) or nothing. What gives you that impression? Quoting David’s original email: ```js import * as fs from fs; // importing the named exports as an object import Dict from dict; // importing a default export, same as ever ``` As a final note, and at the risk of erring in the world of speculation that Brendan fears, are we just sleepwalking towards pushing people to work around the whole debate with the universal: “are we just sleepwalking” – what are you implying? 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: TC39 vs the community
A minimal, pragmatic and well integrated solution is the ES6 Module Transpiler: https://github.com/square/es6-module-transpiler Additionally, Addy Osmani maintains a comprehensive list of tools: https://github.com/addyosmani/es6-tools Axel On Jun 20, 2014, at 19:54 , Jasper St. Pierre jstpie...@mecheye.net wrote: On Fri, Jun 20, 2014 at 11:39 AM, John Barton johnjbar...@google.com wrote: I started out with a similar opinion. Then I wrote some ES6 code. What we need now is experience from using ES6-modules. We have plenty of decent implementations. We've built nodejs and browser applications based on ES6 modules. That experience shows that the ES6 solution is modestly superior to any ES5 solution. Moreover the ES6 solution interoperates with the main ES5 solutions. Are there projects which attempted to use ES6 modules but where unable to succeed because of technical barriers? As a developer currently writing ES5 code, what's the best way to try out writing ES6 code that uses modules? Every time I try and look at bootstrapping ES6 with modules, I can't figure it out. A Get Started Trying It Out guide would go a long way, I feel. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ModuleImport
That’s a good solution. Logically, `import { * } from fs` may make more
sense, but I prefer the “unbraced” asterisk, because it results in less clutter.
Does the proposed syntax clash with `export * FromClause` (which, I’m assuming,
re-exports everything, not just the named exports)?
I’d prefer it if named exports and a default export were mutually exclusive,
but I understand that is off the table(?) Which is also fine with me…
Axel
On Jun 19, 2014, at 10:15 , David Herman dher...@mozilla.com wrote:
## Proposal
OK, so we're talking about a better syntax for importing a module and binding
its named exports to a variable (as distinct from importing a module and
binding its default export to a variable). Here's my proposal:
```js
import * as fs from fs; // importing the named exports as an object
import Dict from dict; // importing a default export, same as ever
```
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ModuleImport
This is a key sentence in David’s proposal: “ES6 favors the single/default export style, and gives the sweetest syntax to importing the default. Importing named exports can and even should be slightly less concise.” On Jun 19, 2014, at 12:31 , Michał Gołębiowski m.go...@gmail.com wrote: Thanks, Dave, for bringing that up, it shows you're open for feedback. That said (bikeshed begins), what's wrong with: ```js import fs as fs; ``` ? I feel that a lot of effort went in ES6 into reducing boilerplate via e.g. arrow functions, classes etc. but if you start with Node's require, this adds clutter. Compare these 3 forms of importing all the module lodash bindings to an object _: ```js var _ = require(lodash); // Node import * as _ from lodash; // Dave's syntax import lodash as _; ``` -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ModuleImport
On Jun 19, 2014, at 16:17 , John Barton johnjbar...@google.com wrote:
Sorry to be dense, but I would appreciate more elaboration of this sentence:
On Thu, Jun 19, 2014 at 3:40 AM, Axel Rauschmayer a...@rauschma.de wrote:
This is a key sentence in David’s proposal: “ES6 favors the single/default
export style,
What is the single/default export style? If I understand this claim, it
says that a module will typically contain a single export statement, either
named 'default' or not. Is there any evidence to support this? Everything
I've seen contradicts this claim, assuming I understand it.
The syntax is (
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-exports ):
export default AssignmentExpression
and gives the sweetest syntax to importing the default. Importing named
exports can and even should be slightly less concise.”
Could you please give an example? In my experience, export default is rare
or at least divisive since it seems stylistically incompatible with named
exports.
I’m surprised, too. But that seems to be the feedback from people working with
large module-based client-side projects and from the Node.js community: single
exports are most common. I think in client-side projects, one class per module
was reported as a frequent use case:
```js
// MyClass.js
export default class {
...
};
// main.js
import MyClass from MyClass;
```
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ModuleImport
On Jun 19, 2014, at 13:36 , Michał Gołębiowski m.go...@gmail.com wrote:
On Thu, Jun 19, 2014 at 12:40 PM, Axel Rauschmayer a...@rauschma.de wrote:
This is a key sentence in David’s proposal: “ES6 favors the single/default
export style, and gives the sweetest syntax to importing the default.
Importing named exports can and even should be slightly less concise.”
There are a lot of large modules that will not disappear overnight. I assume
ES6's recommendation for such things (Node's fs module, Lo-Dash) is to make
those container objects default exports?
What are you saying? That you find this syntax too verbose?
```js
import * as fs from fs;
```
There is a little more clutter, but it’s only 2 characters longer than:
```js
var fs = require('fs');
```
This design decision does make sense if single-export modules are indeed much
more common. It’s not what I expected, but it does seem to be the 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: ModuleImport
To me this is a bug not a feature; we should keep it simple and just have one
way to get one import from one export.
Just to make a connection to the topic, Dave's intro says:
We've consistently seen confusion between the semantics of ModuleImport
and default export.
For me this confusion lands on default export equally as 'module` import.
Personally, I agree, but many people feel strongly about the single-export use
case. If default exports help with getting ES6 modules adopted more broadly
then the slight increase in complexity is worth it.
Let’s compare. Your approach – slightly more redundant:
```js
// MyClass.js
export class MyClass { ... }
// main1.js
import { MyClass } from MyClass;
// myFunc.js
export function myFunc(...) { ... }
// main2.js
import { myFunc } from myFunc;
```
Default exports:
```js
// MyClass.js
export default class { ... };
// main1.js
import MyClass from MyClass;
// myFunc.js
export default function (...) { ... };
// main2.js
import myFunc from myFunc;
```
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ModuleImport
All good points. I don’t see “TC39 versus the community”, though, I’m seeing
many factions with different opinions.
On Jun 19, 2014, at 21:13 , Domenic Denicola dome...@domenicdenicola.com
wrote:
From: es-discuss es-discuss-boun...@mozilla.org on behalf of James Burke
jrbu...@gmail.com
1) Only allow export default or named exports, not both.
As a modification of the current design, this hurts use cases like
```js
import glob, { sync as syncGlob } from glob;
import _, { zip } from underscore;
```
2) Only allow `export` of one thing from a module, and `import {}` just
means allowing getting the first property on that export. This removes the
named export checking, but that benefit was always a bit weak, even weaker
with the favoring of default export.
I definitely believe that if the community were designing a syntax-based
module format, incorporating the lessons learned so far, it would end up
being along these lines. We've learned enough from browserify and RequireJS's
CommonJS-wrapping to know that a top-level static import form has serious
benefits, but we've also learned that `module.exports =` or `return` are the
recommended and primary pattern, and you can always attach things to that
default export as properties if necessary. (In CommonJS terms, we've
learned that the benefits of typing `exports.x = y` instead of
`module.exports.x = y` are not great enough to outweigh the minor confusion
of having two export forms.)
Unfortunately, that's not the world we live in, and instead TC39 is designing
a module system based on their own priorities. (Static checking of
multi-export names, mutable bindings, etc.)
They've (wisely) decided to add affordances for the community's use cases,
such as layering default exports on top of the multi-export model. As well as
Dave's proposal in this thread to de-grossify usage of modules like fs. By
doing so, they increase their chances of the module system being good
enough for the community, so that the path of least resistance will be to
adopt it, despite it not being designed for them primarily. It's still an
open question whether this will be enough to win over the community from
their existing tools, but with Dave's suggestion I think it has a
better-than-even chance.
The transitional era will be a particularly vulnerable time for TC39's module
design, however: as long as people are using transpilers, there's an
opportunity for a particularly well-crafted, documented, and supported
transpiler to give alternate semantics grounded in the community's preferred
model, and win over enough of an audience to bleed the life out of TC39's
modules. We already see signs of community interest in such ES6+
transpilers, as Angular illustrates. Even a transpiler that maintains a
subset of ES6 syntax would work: if it supported only `export default x`, and
then gave `import { x } from y` destructuring semantics instead of
named-binding-import semantics, that would do the trick. Interesting times.
___
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
ES6 modules (sorry...)
I apologize for this email, but I still don’t understand the current module
design.
**Multi-export modules.** Modules made sense to me as long as they were maps
from names to exported values:
```js
// Module 'library'
export function foo() {
}
export function bar() {
}
// Module 'client1'
import { foo, bar } from 'library';
foo();
bar();
// Module 'client2'
import lib from 'library';
lib.foo();
lib.bar();
```
Compared to CommonJS, the syntax is nicer and less redundant. Additionally, the
curly braces for getting stuff out of a module work, because they look like
destructuring. And you get load-time errors if imports don’t match exports.
**Single-export modules.** Still missing is support for single-export modules,
which could be added as follows (the keyword `default` instead of the asterisk
works just as well, in my opinion).
```js
// Module 'MyClass'
export* class {
};
// Module 'client3'
import* MyClass from 'MyClass';
```
At the moment, it seems to me like multi-export modules and single-export
modules are mixed in a way that makes things difficult to understand.
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: `this` inside modules
I completely agree and was, in fact, going to write my own email on this topic, because I strongly believe we should leave `this` alone in modules. Instead, let’s turn “module this” into a module-local special variable with a name such as `module`, `thisModule`, `currentModule`, etc. On Jun 9, 2014, at 6:25 , Domenic Denicola dome...@domenicdenicola.com wrote: https://gist.github.com/caridy/eefb9b104874465d4e1c#2-whats-the-execution-context-for-a-module seems to indicate `this` will become some sort of module meta object with a variety of abilities: `this.name`, `this.address`, `this.import`, `this.get`, and `this.module`. This seems like another unfortunate addition to the WTFJS canon, as it continues to add more confusing meanings for `this` to the mix. IMO it would be much better to leave `this` as `undefined`, just as it is in strict mode scripts, and thus be able to tell a consistent story that in ES6, `this` is about methods. The current proposal would instead create a world where `this` is about methods most of the time, but is a magic ambient variable in some cases (sloppy scripts, modules). This kind of confusion is evident even in the title of that section: it asks “what is the execution context for a module,” but it is actually talking about `this`, which has nothing to do with [execution contexts][1]. If a magically in-scope binding is necessary to access module meta capabilities, giving it a name like `module` or `System.currentModule` would be much better. [1]: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-execution-contexts ___ 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
Rationale for dropping ModuleImport syntax?
Context: https://gist.github.com/caridy/eefb9b104874465d4e1c#1-moduleimport-syntax-importdeclaration ```js module foo from foo; // drop this import bar from bar; ``` I’m seeing the following contra against dropping ModuleImport syntax: Contra: without a way to access the module object, it is difficult to deal with modules with many exports (e.g.: underscore), but we could fix this by using a reflective API to access imported modules Isn’t this a frequent use case? Which would lead to ugly and very inconsistent code, especially if multiple imports are involved. I also don’t see how CommonJS-style modules could be neatly migrated to ES6 modules if this feature was dropped. I do agree that the ModuleImport reads a bit strange, but that could be fixed, e.g. via a suggestion I’ve seen somewhere: ```js import module foo from foo; ``` -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rationale for dropping ModuleImport syntax?
Isn’t the problem, though, that default-exporting an object prevents static checking? It feels like an abuse of this feature to me. With a ModuleImport statement, you have the choice between selectively importing items and importing everything as an object. With default-exporting an object, you don’t have that choice (you can work around this limitation, but still). I do see your point, but I think module imports are useful when the contents of a module change relatively frequently and/or if there are many items in a module. In other words, I think that is something that will live on (justifiedly so) and should be supported properly. On Jun 9, 2014, at 8:49 , Domenic Denicola dome...@domenicdenicola.com wrote: I am beginning to come around to the removal. It will just encourage module authors to use default exports exclusively (e.g. fs will default-export an object including readFile et al., instead of exporting multiple functions), which will put us squarely back in parity with the CommonJS/AMD systems, and ease migration. If module authors try to use multi-exports, they will get upset users who wish to be able to do `import _ from underscore; _.zip(…)`, but cannot. So instead they will use default exports only, which does allow this familiar style. In the end all of the non-default export forms, and the braced multi-import form, will just be relegated to the “bad parts” bin, and default exports and unbraced single-import will remain in the “good parts” bin, giving us the same CommonJS/AMD world we have today, but with some vestigial syntax unused by popular libraries. From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Axel Rauschmayer Sent: Monday, June 9, 2014 02:39 To: es-discuss list Subject: Rationale for dropping ModuleImport syntax? Context: https://gist.github.com/caridy/eefb9b104874465d4e1c#1-moduleimport-syntax-importdeclaration ```js module foo from foo; // drop this import bar from bar; ``` I’m seeing the following contra against dropping ModuleImport syntax: Contra: without a way to access the module object, it is difficult to deal with modules with many exports (e.g.: underscore), but we could fix this by using a reflective API to access imported modules Isn’t this a frequent use case? Which would lead to ugly and very inconsistent code, especially if multiple imports are involved. I also don’t see how CommonJS-style modules could be neatly migrated to ES6 modules if this feature was dropped. I do agree that the ModuleImport reads a bit strange, but that could be fixed, e.g. via a suggestion I’ve seen somewhere: ```js import module foo from foo; ``` -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rationale for dropping ModuleImport syntax?
Isn't the problem, though, that default-exporting an object prevents static checking? It feels like an abuse of this feature to me. We don't have static checking today, so this is no loss to me. If I understand ES6 modules correctly, importing a non-exported identifier gives you a load-time error (that’s what I meant with “static checking”). If you default-import an object with exports, you only get run-time errors. This is more subjective, but what I like about modules is that they lead us away from objects-as-modules. If default exports, used in this manner, become popular, that won’t really happen. We’ll have pseudo-modules, used inside a module system. (And ES6 modules give enough benefits over ES5 ones without static checking to still have a chance in the marketplace, e.g. they statically require imports being at top-level and string-only, and automatically introduce `use strict` for you.) I agree. I also love tools such as the es6-module-transpiler, which allow us to move beyond the AMD/CJS schism right now. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `this` inside modules
Axel, using `module` was the first proposal analyzed (3.1 from the gist). I do like it a lot, but other in the meeting opposed to any sort of automagic by wrapping the module execution into a function execution with the `module` argument (a la nodejs), Overloading `this` feels even more magic to me and is much less self-descriptive. Apart from the overloading problems (which are significant!), I don’t see that much of a difference between passing in a value for `this` and setting up a – descriptively named – module-scoped variable. and the fact that `this` is not really the module, it is an object that contains, among other things, a reference to another object with the live binding, a relative import, a relative get, etc. Give it a different name, then. Call it `moduleDescriptor`, `moduleData`, 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: Rationale for dropping ModuleImport syntax?
On the other hand, we’ll have many pseudo-modules, which is also a barrier against making progress later on. On Jun 9, 2014, at 15:51 , John Barton johnjbar...@google.com wrote: If the 'module' form is left out, it can be added later. If the 'module' form is left in, it can never be removed. jjb On Mon, Jun 9, 2014 at 6:39 AM, Axel Rauschmayer a...@rauschma.de wrote: Isn't the problem, though, that default-exporting an object prevents static checking? It feels like an abuse of this feature to me. We don't have static checking today, so this is no loss to me. If I understand ES6 modules correctly, importing a non-exported identifier gives you a load-time error (that’s what I meant with “static checking”). If you default-import an object with exports, you only get run-time errors. This is more subjective, but what I like about modules is that they lead us away from objects-as-modules. If default exports, used in this manner, become popular, that won’t really happen. We’ll have pseudo-modules, used inside a module system. (And ES6 modules give enough benefits over ES5 ones without static checking to still have a chance in the marketplace, e.g. they statically require imports being at top-level and string-only, and automatically introduce `use strict` for you.) I agree. I also love tools such as the es6-module-transpiler, which allow us to move beyond the AMD/CJS schism right now. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ 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: Rationale for dropping ModuleImport syntax?
I’m assuming that people will default-export objects (for Underscore.js-like libraries). I’d call those pseudo-modules, because one would be partially working around the module system (no load-time errors!). Maybe we’ll import modules like this [^1], but that feels syntactically inconsistent to me and you don’t get load-time errors, either: ```js import Underscore; const _ = System.get(Underscore); ``` [^1]: https://gist.github.com/domenic/2230a7195fa0de31a227 On Jun 9, 2014, at 16:28 , John Barton johnjbar...@google.com wrote: On Mon, Jun 9, 2014 at 6:54 AM, Axel Rauschmayer a...@rauschma.de wrote: On the other hand, we’ll have many pseudo-modules, which is also a barrier against making progress later on. Sorry, I don't understand what a pseudo-module is. Are you saying that the core import/export system is not correct and that we should have a system based exclusively on 'module'? jjb -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Rationale for dropping ModuleImport syntax?
As an aside, it is yet to be seen whether the default export thing is the
best way, or the bad part itself. We don't have the real world experience
yet to answer that.
I’d even argue that they led to the predicament that we are currently in.
If the default export didn’t look like “the module”, things would, in my
opinion, be easier to understand:
```js
import _ from Underscore;
import { flatten, union } from Underscore;
import default someFunction from single_function_module;
```
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Current module path
Actually, that is something that I do understand. esdiscussions *can* be unproductive and emotional. Thus: it’s a tricky balance – getting work done vs. keeping everybody informed and getting feedback. I don’t believe in design by democracy. David Herman has mentioned on Twitter that he’ll write up the rationales for the decisions in a Gist in the coming week. I’m looking forward to reading that. On Jun 9, 2014, at 17:27 , Kevin Smith zenpars...@gmail.com wrote: On a meta level, I'm continually frustrated by the fact that participants in the module design refuse to share their ideas on es-discuss until a TC39 meeting review is posted (which usually coincides with some kind of resolution). Community input is a good thing, right? On Sat, Jun 7, 2014 at 11:29 PM, Kevin Smith zenpars...@gmail.com wrote: we should have some concrete examples in about a week, in the meantime, here are the informal notes from the breakout session about modules (from two days ago): https://gist.github.com/caridy/eefb9b104874465d4e1c Thank you for providing this link. I see several names that I do not recognize as TC39 members from previous meeting notes. May I ask who is currently working on the module design? Thanks, Kevin ___ 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
Publication date of ES7?
Sorry, I tried finding it (e.g. on [1] and the mailing list), but couldn’t: when is the currently planned publication date of ECMAScript 7? Thanks! Axel [1] https://github.com/tc39/ecma262 -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Idea for ECMAScript 7: Number.compare(a, b)
It’d be nice to have a built-in way for comparing numbers, e.g. when sorting arrays. ```js // Compact ECMAScript 6 solution // Risk: number overflow [1, 5, 3, 12, 2].sort((a,b) = a-b) // Proposed new function: [1, 5, 3, 12, 2].sort(Number.compare) ``` -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: My ECMAScript 7 wishlist
* `Function.empty` - a standard empty function that can be used when you just
want an empty function (IMHO, it indicates intent much better than other
options toda).
Ironically, that’s what Function.prototype is. But using that object in that
capacity is beyond confusing. I’d prefer a different name such as “noop” or
“doNothing”; “empty” doesn’t feel right in the context of something executable.
Also, I don’t find using an empty arrow function too bad (to me, it looks quite
intention-revealing):
```js
someAsyncMethod(() = {});
```
--
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 Existential Operator
Dmitry Soshnikov wrote: Will the Existential Operator for properly accessors be something interesting to consider for ES7 spec? Currently CoffeeScript uses it well. Please see http://esdiscuss.org/topic/sept-18-tc39-meeting-notes#content-2 and find ARB: This is non-compositional. David seems to suggest a compositional version: `o?.p?.q?.r` I’m assuming that the left-hand side of `value?.prop` is an arbitrary value and that the property access is only made if that value is neither `undefined` nor `null`. AFAICT that’s also how CoffeeScript’s existential operator works. I’m ambivalent about it, though: it would be useful, but would also add complexity to the language. -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Bytecode
What is the best “bytecode isn’t everything” article that exists? The “the web needs bytecode” meme comes up incredibly often, I’d like to have something good to point to, as an answer. This one looks good: http://mozakai.blogspot.de/2013/05/the-elusive-universal-web-bytecode.html Thanks! Axel -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de Check out my new book: SpeakingJS.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
