I'm trying to understand the options for exporting things from a module.
Here's how I think it works, mostly based on what I see in Traceur.
Does any of this look wrong?
To export a value,
export var someName = someValue;
To export a function,
export function someName(args) { ... };
To export
Have you ever used JavaScript module systems before? If so, the idea of a
default export should be somewhat familiar…
On Mar 14, 2014, at 6:31, Mark Volkmann r.mark.volkm...@gmail.com wrote:
I'm trying to understand the options for exporting things from a module.
Here's how I think it
I have used Node.js extensively. In that environment, as I'm sure you know,
a module exports one thing. It can be an object with lots of properties on
it, a single function, or a single value. I suppose you could say that all
Node has is a default export which is the one thing the module exports.
I'm trying to understand how that compares to ES6 modules. I see how in
ES6 I can import specific things from a module or I can import everything a
module exports.
You can't really import all exported bindings. You can import the module
instance object itself:
module M from wherever;
I understand it's hard to make changes after a certain point. It's too bad
though that developers will have to remember that the way to import a few
things from a module is:
import {foo, bar} from 'somewhere';
but the way to import the whole module is:
module SomeModule from 'somewhere';
Importing is nothing like destructuring. You import mutable bindings; you don't
do assignment. I'm very glad that different syntax is used for each case.
From: Mark Volkmann r.mark.volkm...@gmail.com
Sent: Friday, March 14, 2014 10:19
To: Kevin Smith
Cc: Domenic
What is a 'mutable binding'?
On Fri, Mar 14, 2014 at 7:30 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Importing is nothing like destructuring. You import mutable bindings;
you don't do assignment. I'm very glad that different syntax is used for
each case.
```js
// module1.js
export let foo = 5;
export function changeFoo() {
foo = 10;
}
// module2.js
import { foo, changeFoo } from ./module1;
// Import imports mutable bindings
// So calling changeFoo will change the foo in current scope (and original
scope)
console.log(foo); // 5
On Fri, Mar 14, 2014 at 10:07 AM, Mark Volkmann
r.mark.volkm...@gmail.comwrote:
On Fri, Mar 14, 2014 at 8:54 AM, Kevin Smith zenpars...@gmail.com wrote:
I'm trying to understand how that compares to ES6 modules. I see how in
ES6 I can import specific things from a module or I can import
Is the common use case for export default when you want to give users of
the module an easy way to obtain a single function?
So instead of users doing this:
import {someFn} from 'wherever';
they can do this:
import someFn from 'wherever';
On Fri, Mar 14, 2014 at 9:40 AM, Rick Waldron
Indeed. If you have used Node.js extensively, I am sure you are familiar with
this paradigm.
From: es-discuss es-discuss-boun...@mozilla.org on behalf of Mark Volkmann
r.mark.volkm...@gmail.com
Sent: Friday, March 14, 2014 10:50
To: Rick Waldron
Cc:
Because it doesn't allow for the Assignment Expression form (specifically,
function expressions) that developers expect to be able to write:
export default function() {}
The alternative here is:
function MyThing() {}
export { MyThing as default };
Which is more clear, more
Sigh. The example just better demonstrates how clunky the syntax is
and how surprising the semantics can be. :(
rant
I hope one of the CommonJS or RequireJS folks write a good ES6 module
loader so that I can continue to use reasonable syntax and ignore all
of this.
This really smells like
On Fri, Mar 14, 2014 at 11:04 AM, Kevin Smith zenpars...@gmail.com wrote:
Because it doesn't allow for the Assignment Expression form
(specifically, function expressions) that developers expect to be able to
write:
export default function() {}
The alternative here is:
function
On Fri, Mar 14, 2014 at 9:15 AM, Rick Waldron waldron.r...@gmail.comwrote:
On Fri, Mar 14, 2014 at 11:04 AM, Kevin Smith zenpars...@gmail.comwrote:
Because it doesn't allow for the Assignment Expression form
(specifically, function expressions) that developers expect to be able to
var f = function a() {};
a(); // nope.
Sure, note the equals (which is my point).
var D = class C {};
And no one would expect to be able to this:
var c = new C();
Same thing. Note the equals, which gives the reader the necessary visual
cue that we are entering an
I like that more I read about this, more the `with` statement comes into my
mind ...
console.log(foo); // Oh, yeah, this really means module1.foo
looks like that
changeFoo();
here the implicit context ? ... if so, I have no idea which one it is and
why ... also, can I change it?
Maybe I
On Fri, Mar 14, 2014 at 12:24 PM, Kevin Smith zenpars...@gmail.com wrote:
var f = function a() {};
a(); // nope.
Sure, note the equals (which is my point).
var D = class C {};
And no one would expect to be able to this:
var c = new C();
Same thing. Note the equals, which
I don't understand this claim, any legal AssignmentExpression form is
allowed.
I've said this before, but without the equals it looks too much like a
declaration:
export default class C {}
var c = new C(); // No C defined, WTF?
Why is this surprising?
It is surprising
JSC has been trying to kill off the initialiser expression in the for(in)
statement, but we've encountered a bunch of reasonably significant content that
breaks with it disallowed (a particularly prominent one currently is
http://battlelog.battlefield.com/bf4/), so we will be bringing back
On Mar 14, 2014, at 9:27 AM, John Barton johnjbar...@google.com wrote:
I've used es6 modules for several months now and I'm curious to know when I
would want to leverage mutable bindings.
So cycles work!
// model.js
import View from view;
export default class Model {
...
On Mar 14, 2014, at 9:37 AM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
I like that more I read about this, more the `with` statement comes into my
mind ...
There's nothing like this in JS today, so if you're only looking for precedent
there, you're only going to be able to come
On Mar 14, 2014, at 10:50 AM, Russell Leggett russell.legg...@gmail.com wrote:
I completely agree with this. It looks like a modifier.
This is a good point, and folks working on the Square transpiler noticed this,
too. I think there's a more surgical fix, though (and I'm not entertaining
Sad panda. At least we can disable it in strict mode, right?
And who knows, maybe some day, some day...
Dave, dreaming of ES24
On Mar 13, 2014, at 4:59 PM, Oliver Hunt oli...@apple.com wrote:
JSC has been trying to kill off the initialiser expression in the for(in)
statement, but we've
From: es-discuss es-discuss-boun...@mozilla.org on behalf of David Herman
dher...@mozilla.com
So I think we should consider doing the same thing as we do for
ExpressionStatement:
...
This actually results in no net change to the language syntax, but it allows
us to change the scoping
ExportDeclaration :
...
export default FunctionDeclaration ;
export default ClassDeclaration ;
export default [lookahead !in { function, class }]
AssignmentExpression ;
I think this would allay most of my concerns.
David Herman wrote:
I think we're seeing the exact same phenomenon with `export default` -- the
modifiers make it look more like a declaration context. So I think we should
consider doing the same thing as we do for ExpressionStatement: snip
I agree with the confusion (due in part because
On Fri, Mar 14, 2014 at 11:42 AM, David Herman dher...@mozilla.com wrote:
When you export from a module, you're exporting bindings, rather than
values. This means you can refactor between
module m from foo;
...
m.bar
and
import { bar } from foo;
...
bar
and
David I know the analogy was weak but since indeed you said there's nothing
like that, I named the one that felt somehow close because of some implicit
behavior.
I am personally easy going on modules, I like node.js require and I think
that behind an await like approach could work asynchronously
On Fri, Mar 14, 2014 at 3:34 PM, John Barton johnjbar...@google.com wrote:
On Fri, Mar 14, 2014 at 11:42 AM, David Herman dher...@mozilla.com wrote:
When you export from a module, you're exporting bindings, rather than
values. This means you can refactor between
module m from foo;
On Fri, Mar 14, 2014 at 12:29 PM, David Herman dher...@mozilla.com wrote:
Sad panda. At least we can disable it in strict mode, right?
yes!
And who knows, maybe some day, some day...
Dave, dreaming of ES24
I'll hazard a public prediction for the record:
Since ES6 does implicit strict
On 14 March 2014 00:59, Oliver Hunt oli...@apple.com wrote:
JSC has been trying to kill off the initialiser expression in the for(in)
statement, but we've encountered a bunch of reasonably significant content
that breaks with it disallowed (a particularly prominent one currently is
Andreas Rossberg wrote:
On 14 March 2014 00:59, Oliver Huntoli...@apple.com wrote:
JSC has been trying to kill off the initialiser expression in the for(in)
statement, but we've encountered a bunch of reasonably significant content
that breaks with it disallowed (a particularly prominent
Brendan Eich wrote:
for (var i = 0 in debug.audio)
BTW, ur-JS in Netscape would not parse this. The optional initializer
fell out of grammar over-reuse in ES1, possibly also works-in-JScript
lobbying (my memory fades but that is where it came from).
/be
JSC has been trying to kill off the initialiser expression in the for(in)
statement, but we've encountered a bunch of reasonably significant content
that breaks with it disallowed (a particularly prominent one currently is
http://battlelog.battlefield.com/bf4/), so we will be bringing back
I'm not married to the AST format I proposed.
I do feel very strongly that each language targeting JS shouldn't have
to write a browser devtools extension for every browser its users want
to debug.
I feel very strongly that users debugging their sources that were
compiled to js should be able to
Geoffrey Garen wrote:
I suggested to Oliver that we accept Identifier = Expression in
Expression” as valid syntax, but drop = Expression” from the parse
tree after the fact.
Note that the issue here is only legacy that uses 'var' before
Identifier. So you can't be sure of no compat break,
On Fri, Mar 14, 2014 at 3:31 PM, Brendan Eich bren...@mozilla.org wrote:
Geoffrey Garen wrote:
I suggested to Oliver that we accept Identifier = Expression in
Expression” as valid syntax, but drop = Expression” from the parse tree
after the fact.
Note that the issue here is only legacy
Does ES6 add any new ways to iterate over the values in an object?
I've done a lot of searching, but haven't seen anything.
I'm wondering if there is something more elegant than this:
Object.keys(myObj).forEach(function (key) {
let obj = myObj[key];
// do something with obj
});
--
R. Mark
On 3/14/2014 5:16 PM, Mark Volkmann wrote:
Does ES6 add any new ways to iterate over the values in an object?
I've done a lot of searching, but haven't seen anything.
I'm wondering if there is something more elegant than this:
Object.keys(myObj).forEach(function (key) {
let obj = myObj[key];
Peter van der Zee wrote:
Which browsers currently don't accept this construct? I wasn't even
aware that JSC didn't support it at some point.
Did anyone say JSC lacked support? I think KJS followed ES3, and this
was in the ES1 grammar, so I doubt it was never supported.
Minifiers might
41 matches
Mail list logo
