TLDR: We should consider deferring specialized syntax for exporting a
default binding until after ES6.
In the current draft, there are 3 ways to export a default binding:
1. Export a local binding with the name default:
class Parser { ... }
export { Parser as default };
2. Use
Good observation. However, if I were to simplify, I’d only keep #3. #1 and #2
look more syntactically questionable to me (kind of abusing names as
keywords/markers).
Axel
On 05 Dec 2013, at 15:18 , Kevin Smith zenpars...@gmail.com wrote:
TLDR: We should consider deferring specialized syntax
Good observation. However, if I were to simplify, I’d only keep #3. #1 and
#2 look more syntactically questionable to me (kind of abusing names as
keywords/markers).
#1 is the base case because it is completely general. Any IdentifierName
may appear in the as clause.
export { x as
#2 was removed at the hallway discussion of the face to face meeting. Do
you still think we should remove #3?
On Thu, Dec 5, 2013 at 10:48 AM, Kevin Smith zenpars...@gmail.com wrote:
Good observation. However, if I were to simplify, I’d only keep #3. #1 and
#2 look more syntactically
#2 was removed at the hallway discussion of the face to face meeting. Do
you still think we should remove #3?
My only real issue with #3 is that it raises a footgun flag for me:
export default function parse1JS(code) {
// ...
}
parse1JS.foo = bar; // Surprise!
On 5 December 2013 16:48, Kevin Smith zenpars...@gmail.com wrote:
#1 is the base case because it is completely general. Any IdentifierName
may appear in the as clause.
export { x as delete, y as new, z as default }; // Perfectly fine!
I certainly wouldn't mind this simplification either.
Although the import side has this one extra syntactic special case for
defaults:
import x, {y as z, ...} from ...
That seems really redundant. I assume mixing default import with
others will be an extremely rare case, and when really needed, can
easily be expressed as either
import
The `import crazy, {more as boo} from 'name'` needs to go away.
https://bugs.ecmascript.org/show_bug.cgi?id=2287
It is also bad because the order there is fixed and you cannot interleave.
On Thu, Dec 5, 2013 at 11:25 AM, Kevin Smith zenpars...@gmail.com wrote:
Although the import side has
On Dec 4, 2013, at 11:39 PM, Carsten Bormann wrote:
On 05 Dec 2013, at 06:08, Tim Bray tb...@textuality.com wrote:
FWIW, I have never understood what the ECMAnauts mean by the word
“semantics” in this context, so I have no idea whether I agree with this
statement.
As one of the
The ES6 draft specifies that `map()`, when applied to a typed array,
yields another instance of that same type. For converting between
array types, the `from()` method is added:
var f1 = new Float32Array();
...
var f2 = f1.map(x = x * 2); // Yields Float32Array
var i1 =
10 matches
Mail list logo
