Re: Trailing commas in arguments list, imports and destructuring
Note that you’ve got the experimental REPL option enabled which means all
transformers are enabled which includes the `es7.trailingFunctionCommas` one
which allows trailing commas in function parameter lists and call expressions.
The destructuring grammar does allow trailing commas
(https://people.mozilla.org/~jorendorff/es6-draft.html#sec-destructuring-binding-patterns):
ObjectBindingPattern[Yield,GeneratorParameter] :
{ BindingPropertyList[?Yield,?GeneratorParameter] , }
ArrayBindingPattern[Yield,GeneratorParameter] :
[ BindingElementList[?Yield, ?GeneratorParameter] , Elisionopt
BindingRestElement[?Yield, ?GeneratorParameter]opt]
And import specifiers allow trailing commas too
(https://people.mozilla.org/~jorendorff/es6-draft.html#sec-imports
):
NamedImports :
{ ImportsList , }
On Wed, Apr 22, 2015 at 4:16 PM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
I just noticed that Babel support trailing commas in function arguments
lists, imports and destructuring as well:
http://babeljs.io/repl/#?experimental=trueevaluate=trueloose=falsespec=falsecode=import%20%7B%0A%20%20voo%2C%0A%20%20doo%2C%0A%7D%20from%20%22.%2Fdat.js%22%3B%0A%0Alet%20%7B%0A%20%20x%2C%0A%20%20y%2C%0A%7D%20%3D%20voo%3B%0A%0Alet%20%5B%0A%20%20z%2C%0A%20%20m%2C%0A%5D%20%3D%20doo%3B%0A%0Afunction%20qoo%20(%0A%20%20x%2C%0A%20%20y%2C%0A)%20%7B%7D
Is this correct behavior? I'm not
FWIW as I already use trailing commas object and array literals for better
diffs, I really like this feature as it comes in handy especially in
function signatures where you define types (TypeScript/flow style
annotations), for example:
function sort T (
array : ArrayT,
compareFn : ((left: T, right: T) = number),
) : ArrayT {
...
}
as well as import statements for modules that declare constants:
import {
BRAND_COLOR,
DEFAULT_TEXT_COLOR,
DARK_GRAY,
LIGHT_GRAY,
} from ./constants/COLORS;
not to mention options object style function signatures:
class Person {
constructor ({
firstName,
lastName,
birthDate,
country,
city,
zipCode,
}) {
this.firstName = firstName;
this.lastName = lastName;
this.birthDate = birthDate;
this.country = country;
this.city = city;
this.zipCode = zipCode;
}
}
To me, the spec language as per Jason's HTML version looks like at least
for destructuring this is supported, but at least I can't read the spec to
allow trailing commas in function signatures. At least this doesn't seem to
be incorporated into the spec:
https://esdiscuss.org/notes/2014-09/trailing_comma_proposal.pdf
Is the proposal still on track for ES7 and am I correct in my reading of
the destructuring allowing trailing commas?___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Trailing commas in arguments list, imports and destructuring
I just noticed that Babel support trailing commas in function arguments
lists, imports and destructuring as well:
http://babeljs.io/repl/#?experimental=trueevaluate=trueloose=falsespec=falsecode=import%20%7B%0A%20%20voo%2C%0A%20%20doo%2C%0A%7D%20from%20%22.%2Fdat.js%22%3B%0A%0Alet%20%7B%0A%20%20x%2C%0A%20%20y%2C%0A%7D%20%3D%20voo%3B%0A%0Alet%20%5B%0A%20%20z%2C%0A%20%20m%2C%0A%5D%20%3D%20doo%3B%0A%0Afunction%20qoo%20(%0A%20%20x%2C%0A%20%20y%2C%0A)%20%7B%7D
Is this correct behavior? I'm not
FWIW as I already use trailing commas object and array literals for better
diffs, I really like this feature as it comes in handy especially in
function signatures where you define types (TypeScript/flow style
annotations), for example:
function sort T (
array : ArrayT,
compareFn : ((left: T, right: T) = number),
) : ArrayT {
...
}
as well as import statements for modules that declare constants:
import {
BRAND_COLOR,
DEFAULT_TEXT_COLOR,
DARK_GRAY,
LIGHT_GRAY,
} from ./constants/COLORS;
not to mention options object style function signatures:
class Person {
constructor ({
firstName,
lastName,
birthDate,
country,
city,
zipCode,
}) {
this.firstName = firstName;
this.lastName = lastName;
this.birthDate = birthDate;
this.country = country;
this.city = city;
this.zipCode = zipCode;
}
}
To me, the spec language as per Jason's HTML version looks like at least
for destructuring this is supported, but at least I can't read the spec to
allow trailing commas in function signatures. At least this doesn't seem to
be incorporated into the spec:
https://esdiscuss.org/notes/2014-09/trailing_comma_proposal.pdf
Is the proposal still on track for ES7 and am I correct in my reading of
the destructuring allowing trailing commas?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: super.prop assignment can silently overwrite non-writable properties
2015-04-21 22:15 GMT+02:00 Allen Wirfs-Brock al...@wirfs-brock.com:
Yes, I considered that possibility in deciding upon the proposed change.
The reason I error out if the Receiver property is an accessor is because I
think the most likely way this scenario will occur is when that that access
includes a `super.prop` assignment. That would result in an infinite
[[Set]] recursion. For example:
```
var y = {
__proto__: x,
set prop(v) {
// ...
super.prop = v;
}
};
y.prop = 42;
```
Assuming `x` here is the object where prop is bound to an accessor, can
you clarify how this would lead to an infinite recursion?
y.prop = 42; // 9.1.9 step 2 binds ownDesc to y's accessor, and calls it in
step 9
super.prop = v; // 9.1.9 step 2 binds ownDesc to x's accessor, and calls it
in step 9
x's setter then runs `v = n;` and the assignment terminates
I must be missing something?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?
Can you clarify what you mean about bundling? Unless I've missed something, the ES6 module system does not have a story for bundling at all. Of course formats can be invented in userland but I'm not sure that they are any easier to implement than say AMD's. I might have missed something though, looking forward to your reply. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: super.prop assignment can silently overwrite non-writable properties
2015-04-21 21:52 GMT+02:00 Kevin Smith zenpars...@gmail.com: Another interpretation might be that since you've explicitly stated an intention to bypass the receiver's setter, falling back to that setter would be a bug. No, that wouldn't be right. To clarify, Reflect.set takes the following params: Reflect.set(lookupObject, propertyName, propertyValue, receiverObject) It states that we want to start the lookup of propertyName in lookupObject, but eventually, the object to be updated is receiverObject. The reason for the split between lookupObject and receiverObject is so that Reflect.set (or the [[Set]] internal method, which mirrors it) can encode a prototype chain walk. For a regular property assignment, we always start at the receiverObject, that is, we initially call: Reflect.set(receiverObject, propertyName, propertyValue, receiverObject) As long as we don't find propertyName, we recurse: Reflect.set(receiverObject.__proto__, propertyName, propertyValue, receiverObject) Reflect.set(receiverObject.__proto__.__proto__, propertyName, propertyValue, receiverObject) ... and so on until we hit the root. The only reason why [[Set]] wants to climb the prototype chain in this way is to see if there are non-writable inherited properties. However, if the receiverObject has overridden that property (either with an accessor or a writable property), then the inherited property takes precedence. In normal ES5 code, since lookup is guaranteed to start at receiverObject, this precedence is implicitly guaranteed. In ES6, with both `super.prop` syntax and Reflect.set, the programmer can explicitly start the lookup higher up the prototype chain. The implicit precedence of the receiverObject's property is now no longer guaranteed, because we've skipped looking for the property in receiverObject first. That's why I think in step 5.c and onward, we must now explicitly ensure that existingDescriptor takes precedence over the newly defined descriptor. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: super.prop assignment can silently overwrite non-writable properties
```
var y = {
__proto__: x,
set prop(v) {
// ...
super.prop = v;
}
};
y.prop = 42;
```
Assuming `x` here is the object where prop is bound to an accessor, can
you clarify how this would lead to an infinite recursion?
Assume let x = {}; (i.e. no property definition for prop on x.)
y is the receiver, so if you fall back to calling the receiver's accessor
somewhere in 5.e, you get infinite recursion.
Falling back to the receiver's accessor would be a bug in this case.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
