Date: Fri, 27 Jul 2012 09:09:26 -0700
From: bren...@mozilla.org
To: infinte.c...@hotmail.com
CC: sa...@ccs.neu.edu; es-discuss@mozilla.org
Subject: Re: ES Modules: suggestions for improvement
BelleveInvis wrote:
Date: Tue, 24 Jul 2012 14:11:38 -0700
From: bren...@mozilla.org
Date: Tue, 24 Jul 2012 14:11:38 -0700
From: bren...@mozilla.org
To: sa...@ccs.neu.edu
Subject: Re: ES Modules: suggestions for improvement
CC: es-discuss@mozilla.org
Sam Tobin-Hochstadt wrote:
But I don't think we should ban people from
using `import *` because sometimes it's hard
On Tue, Jul 24, 2012 at 5:11 PM, Brendan Eich bren...@mozilla.org wrote:
Sam Tobin-Hochstadt wrote:
But I don't think we should ban people from
using `import *` because sometimes it's hard to reason about.
Just to focus on import *, here's where I am:
I'm in favor of deferring (not to
BelleveInvis wrote:
Date: Tue, 24 Jul 2012 14:11:38 -0700
From: bren...@mozilla.org
To: sa...@ccs.neu.edu
Subject: Re: ES Modules: suggestions for improvement
CC: es-discuss@mozilla.org
Sam Tobin-Hochstadt wrote:
But I don't think we should ban people from
using `import
On the subject of 'exporting one value', there are a few things to say:
1. It's been asserted repeatedly that libraries that export 'just one
value' are a better design, but while this is excellent style in lots
of cases, I don't think a persuasive case has been made that this
should be the
On 24 July 2012 05:03, Claus Reinke claus.rei...@talk21.com wrote:
Hm, I hadn't thought about that, but my intuition tells me that
there should be an export object for every module, with just the
exports, and that this export object should be accessible from the module
object.
Being able to
Being able to access the export object from the module object enables a
pattern we use locally, which is roughly
require(myModule).configParameter = xyz;
..
exports.errorReporter, exports.configParameter are then used heavily within
the module -- normally, they are not even set by the user,
[I've elided some points and comments: I was trying to summarize
what seemed to me the core issues in this discussion; if my summary
was unclear, it won't help to add more text; if my summary was clear,
but the disagreements persist, adding more text won't help, either]
Here I've come
On Tue, Jul 24, 2012 at 1:11 PM, Claus Reinke claus.rei...@talk21.com wrote:
Here I've come around to Isaac's opinion that 'import *' is a
step too far. Previously, I said this is a convenient bad habit
that might be left to linters. But that was based on experience
with statically
Sam Tobin-Hochstadt wrote:
But I don't think we should ban people from
using `import *` because sometimes it's hard to reason about.
Just to focus on import *, here's where I am:
I'm in favor of deferring (not to say cutting) import *, in order to get
ES6 modules spec'ed and avoid protracted
On Sat, Jul 21, 2012 at 5:03 AM, Claus Reinke claus.rei...@talk21.com wrote:
If you want to export a bag of functions, then put the functions on an
object, and export the object.
It *is* making it trickier to figure out how to add types and macros,
but I'm less excited about those features
On Jul 20, 2012, at 9:23 PM, Isaac Schlueter wrote:
On Fri, Jun 29, 2012 at 4:33 PM, David Herman dher...@mozilla.com wrote:
var fs = require('fs')
// no path here...
function notCoveredByTests () {
fs.open(path.resolve(yabbadabba), ...)
}
Right.
How would any of this solve that?
If you want to export a bag of functions, then put the functions on an
object, and export the object.
It *is* making it trickier to figure out how to add types and macros,
but I'm less excited about those features than I am about making our
existing problems easier to solve.
It's not trickier,
Sorry for my long delay in responding.
On Fri, Jun 29, 2012 at 4:33 PM, David Herman dher...@mozilla.com wrote:
var fs = require('fs')
// no path here...
function notCoveredByTests () {
fs.open(path.resolve(yabbadabba), ...)
}
Right.
How would any of this solve that?
Because `path` is
On 30 June 2012 01:49, Axel Rauschmayer a...@rauschma.de wrote:
So packages are like 30% of a module system.
Coming from ML, I have to disagree strongly -- Java's packages are at most
3% of a module system. ;)
/Andreas
___
es-discuss mailing list
Strongly concur with Andreas. Citing Java is fraught beyond belief.
Andreas Rossberg rossb...@google.com wrote:
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Jun 27, 2012, at 1:06 PM, Isaac Schlueter wrote:
On Wed, Jun 27, 2012 at 11:51 AM, David Herman dher...@mozilla.com wrote:
That bug was particularly bad because it was *assigning* to an accidentally
global variable. But in my personal experience I certainly forget to import
common
In Java, they didn't even *have* a module system because classes did
double-duty as a data abstraction, a constructor, a type definition and a
module.
Not that it affects your arguments, but that is not entirely true. With
packages, you’ve always had a namespacing mechanism that was easy to
I think we all agree that global isolation is the core purpose of a
module system. (Is that incorrect?)
Partly agree? I believe that obviating the *need* for globals is the core
purpose of a module system. I don't believe that modules should necessarily be
strictly separated. Modules should
On Thu, Jun 28, 2012 at 10:40 AM, Kevin Smith khs4...@gmail.com wrote:
script src=/assets/add_blaster.js
script
module main {
import go from add_blaster;
console.log(go(4,5));
}
/script
That's *not* what I'd call a forward-compatible solution since you still
What James asked for was a solution for how libraries such as jquery
or backbone could be implemented so that they work in both worlds,
which is what I provided.
From James' point-of-view, though (correct me if I'm wrong, James), this
would be a step backward from current AMD usability.
No,
On Thu, Jun 28, 2012 at 7:56 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Thu, Jun 28, 2012 at 10:40 AM, Kevin Smith khs4...@gmail.com wrote:
script src=/assets/add_blaster.js
script
module main {
import go from add_blaster;
console.log(go(4,5));
}
/script
David Bruant wrote:
Le 26/06/2012 16:44, David Bruant a écrit :
Also relevant to this thread, post on the same topic by Isaacs
(node.js lead) : http://blog.izs.me/post/25906678790/on-es-6-modules
Furthermore, |let| already gives us destructuring assignment. If a
module exports a bunch of
Le 27/06/2012 10:31, Brendan Eich a écrit :
David Bruant wrote:
Le 26/06/2012 16:44, David Bruant a écrit :
Also relevant to this thread, post on the same topic by Isaacs
(node.js lead) : http://blog.izs.me/post/25906678790/on-es-6-modules
Furthermore, |let| already gives us destructuring
David Bruant wrote:
Le 27/06/2012 10:31, Brendan Eich a écrit :
David Bruant wrote:
Le 26/06/2012 16:44, David Bruant a écrit :
Also relevant to this thread, post on the same topic by Isaacs
(node.js lead) : http://blog.izs.me/post/25906678790/on-es-6-modules
Furthermore, |let| already gives
Le 27/06/2012 11:09, Brendan Eich a écrit :
David Bruant wrote:
Le 27/06/2012 10:31, Brendan Eich a écrit :
David Bruant wrote:
Le 26/06/2012 16:44, David Bruant a écrit :
Also relevant to this thread, post on the same topic by Isaacs
(node.js lead) :
David Bruant wrote:
Import checking is definitely a feature that's worth it, but Isaacs
idea to being able to import jQuery (or any library of course) as is
by having the module global scope into the export object without
polluting the actual global object seems to is definitely a win.
The other point people seem to miss about import as a special binding form
is not just that it can be restricted grammatically to be
control-insensitive by construction: it's that static export vs. import
checking can be done to catch typos.
As long as the exported names are static, it's
I think a stand-up fight about this sounds wonderful.
I am not at all convinced that typo-checking is anywhere near worth
the price tag, or is even a problem. Most of the alleged needs for
type-checking are a bit dubious to me; that's not really what JS is
all about.
It would be great for one
Kevin Smith wrote:
The other point people seem to miss about import as a special
binding form is not just that it can be restricted grammatically
to be control-insensitive by construction: it's that static export
vs. import checking can be done to catch typos.
As long as the
Isaac Schlueter wrote:
I think a stand-up fight about this sounds wonderful.
Ok, great. But:
I am not at all convinced that typo-checking is anywhere near worth
the price tag, or is even a problem. Most of the alleged needs for
type-checking are a bit dubious to me; that's not really what
On Jun 27, 2012, at 8:46 AM, Isaac Schlueter wrote:
I am not at all convinced that typo-checking is anywhere near worth
the price tag, or is even a problem. Most of the alleged needs for
type-checking are a bit dubious to me; that's not really what JS is
all about.
Well, not JavaScripty is
On Wed, Jun 27, 2012 at 9:39 AM, Brendan Eich bren...@mozilla.org wrote:
First, what we propose is not type-checking.
Oh, ok. I misunderstood. Let's not say another word about type checking :)
var foo = 42;
... foop ...
throws at runtime in ES1-5 if evaluation reaches the foop use, and
On Jun 27, 2012, at 10:32 AM, Isaac Schlueter wrote:
On Wed, Jun 27, 2012 at 9:39 AM, Brendan Eich bren...@mozilla.org wrote:
var foo = 42;
... foop ...
throws at runtime in ES1-5 if evaluation reaches the foop use, and (if you
wrap a module around that hunk of code, and there's no
On Wednesday, June 27, 2012 at 10:32 AM, Isaac Schlueter wrote:
I don't think that's a real problem. Can you point to in-the-wild
bugs caused by this? Maybe it's a failure of imagination on my part.
Not sure if it's relevant but based on feedback I receive spotting typoed
variables is one
The client chose to use *. You don't have to use * if you don't want to.
It's a convenience.
The convenience of * comes with a price, of course: (a) the inability to
statically catch undeclared names without also anlayzing external files,
(b) the hazard of name collisions, and (c) the
On Wed, Jun 27, 2012 at 8:43 PM, David Herman dher...@mozilla.com wrote:
On Jun 27, 2012, at 10:32 AM, Isaac Schlueter wrote:
On Wed, Jun 27, 2012 at 9:39 AM, Brendan Eich bren...@mozilla.org wrote:
var foo = 42;
... foop ...
throws at runtime in ES1-5 if evaluation reaches the foop
On Jun 27, 2012, at 11:00 AM, Jussi Kalliokoski wrote:
On Wed, Jun 27, 2012 at 8:43 PM, David Herman dher...@mozilla.com wrote:
http://blog.safeshepherd.com/23/how-one-missing-var-ruined-our-launch/
I don't see how that's at all related to modules or how modules would have
prevented
On Jun 27, 2012, at 10:58 AM, Kevin Smith wrote:
The client chose to use *. You don't have to use * if you don't want to. It's
a convenience.
The convenience of * comes with a price, of course: (a) the inability to
statically catch undeclared names without also anlayzing external files,
Well, this was a relatively high-profile example:
http://blog.safeshepherd.com/23/how-one-missing-var-ruined-our-launch/
That was a bug caused by a lack of global isolation, which current
module systems cannot fix. (Well, node *can* fix it with separate
contexts, but only by harshly
On Wed, Jun 27, 2012 at 9:02 PM, David Herman dher...@mozilla.com wrote:
On Jun 27, 2012, at 11:00 AM, Jussi Kalliokoski wrote:
On Wed, Jun 27, 2012 at 8:43 PM, David Herman dher...@mozilla.com wrote:
http://blog.safeshepherd.com/23/how-one-missing-var-ruined-our-launch/
I don't see how
On Wed, Jun 27, 2012 at 11:15 AM, Isaac Schlueter i...@izs.me wrote:
import {myX: x, myY: y, z} from foo
// comparable to:
let {myX: x, myY: y, z} = require(foo)
Um.. I got the destructuring backwards, didn't I?
Of course not. You can export a mutable object if you want to. You can export
On Wed, Jun 27, 2012 at 9:47 AM, James Burke jrbu...@gmail.com wrote:
The discussion on what is allowed, in particular import *, could still
happen, but at least there would be a baseline that would allow for
them in a way that makes it easier for existing code to transition to
the new
This brings up an interesting point about the modules, that being lazy
loading. One appealing reason to use a module loader instead of just
concatenating the scripts or using multiple script tags is that you can do
feature detection and load polyfills for things you need instead of just
forcing
On Jun 27, 2012, at 11:15 AM, Isaac Schlueter wrote:
That was a bug caused by a lack of global isolation, which current
module systems cannot fix.
It was caused by accidentally creating a global variable instead of a local
variable. Not totally sure what you mean by global isolation? If you
On Tue, Jun 26, 2012 at 2:54 PM, Isaac Schlueter i...@izs.me wrote:
The linked blog post is a very rough cut of where my thoughts are on
the subject. Expect changes and cleanup. It does not represent a
fully-baked (or even half-baked) idea, but more like a general
direction.
Your post makes
On Wed, Jun 27, 2012 at 11:40 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
This brings up an interesting point about the modules, that being lazy
loading. One appealing reason to use a module loader instead of just
concatenating the scripts or using multiple script tags is that you
On Jun 27, 2012, at 11:40 AM, Jussi Kalliokoski wrote:
This brings up an interesting point about the modules, that being lazy
loading. One appealing reason to use a module loader instead of just
concatenating the scripts or using multiple script tags is that you can do
feature detection
As a starter, I'd like to say that jQuery may not be the best example
since it's heavily maintained and it's certainly an exception by
comparison to the massive amount of JavaScript library out there.
Also, jquery seems to attach its properties to the 'window' alias rather
than the top-level
obscured_call could have deleted the 'real' property, and added (or not)
'typo'. There is no way in general to statically check property references
in JS. Static analysis is by definition approximate and while we have some
hot analyses in SpiderMonkey and (to be brought back up soon)
On Wed, Jun 27, 2012 at 11:56 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
Then we can use the module like this:
System.load(add_blaster, function(ab) { return ab.go(4,5); })
or, since we know that add_blaster is a local module:
let { go } = System.get(add_blaster);
go(9,10);
By implementing it in SpiderMonkey! :)
That's cheating! : )
A social note: designing the module system for ES6 is a difficult position
to be in because there's already a more or less de facto module system in
place (derived from CommonJS). It's like an empty field has been
transformed into
I personally really like the current module proposal - I think we could
...benefit from working out how ES6 modules are going to interoperate with
current module systems, though.
(my 17 mo. old hit the send button early)
- Kevin
___
es-discuss
Sure, but I would hate it if this opportunity to create a **better** module
system was dragged down by compatibility with existing ones. We can migrate the
node modules if we need to, but the new system has be compelling enough for us
to do so.
We should identify the short comings of the
On Wed, Jun 27, 2012 at 11:51 AM, David Herman dher...@mozilla.com wrote:
On Jun 27, 2012, at 11:15 AM, Isaac Schlueter wrote:
That was a bug caused by a lack of global isolation, which current
module systems cannot fix.
It was caused by accidentally creating a global variable instead of a
On 27 June 2012 15:45, Kevin Smith khs4...@gmail.com wrote:
By implementing it in SpiderMonkey! :)
That's cheating! : )
A social note: designing the module system for ES6 is a difficult
position to be in because there's already a more or less de facto module
system in place (derived
On Wed, Jun 27, 2012 at 3:37 PM, James Burke jrbu...@gmail.com wrote:
On Wed, Jun 27, 2012 at 11:56 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
Then we can use the module like this:
System.load(add_blaster, function(ab) { return ab.go(4,5); })
or, since we know that add_blaster is
let * = Math;
This is dynamic scoping. The difference between import * and let * is
that
the former is statically scoped, and the latter is dynamically scoped.
I'm sorry, I'm not entirely sure what static scoping means in the context
of JavaScript. Could you clarify? Does it mean that it's
On 27 June 2012 17:21, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
Certainly you shouldn't have to create a userland loader in order to
get examples like I've written to work. You should only ever need to
create a loader if you want to customize things, such as redirecting
some things to
On Wed, Jun 27, 2012 at 5:29 PM, Wes Garland w...@page.ca wrote:
On 27 June 2012 17:21, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
Certainly you shouldn't have to create a userland loader in order to
get examples like I've written to work. You should only ever need to
create a loader if
Thanks Claus, it helped! But I still kind of like the idea I threw in. It's
a footgun, for sure, but a pretty convenient one, kinda like `with`.
Cheers,
Jussi
On Jun 28, 2012 12:25 AM, Claus Reinke claus.rei...@talk21.com wrote:
let * = Math;
This is dynamic scoping. The difference between
On Jun 27, 2012, at June 27, 20121:06 PM, Isaac Schlueter wrote:
I just disagree. I think it's fine if you like that style [one module
exports one thing], and you can use it. But we shouldn't force it on users.
I'm having trouble articulating why it is that module.exports=blah is
better
On 27 June 2012 17:40, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
What request do you send to ask for multiple modules?
We send a request like
/methods/modules?root=pathto/mystuffid=/sha256id=/auth/password
The client canonicalizes each CommonJS dependency to its full (canonical)
path and
On Wed, Jun 27, 2012 at 2:21 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
On Wed, Jun 27, 2012 at 3:37 PM, James Burke jrbu...@gmail.com wrote:
On Wed, Jun 27, 2012 at 11:56 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu
wrote:
Then we can use the module like this:
Also relevant to this thread, post on the same topic by Isaacs (node.js
lead) : http://blog.izs.me/post/25906678790/on-es-6-modules
David
Le 26/06/2012 06:24, James Burke a écrit :
Posted here:
http://tagneto.blogspot.ca/2012/06/es-modules-suggestions-for-improvement.html
Some of it is a
On Tue, Jun 26, 2012 at 10:12 AM, John J Barton
johnjbar...@johnjbarton.com wrote:
As I understand it, two issues drive the need for standardization of
modules:
1) we want one environment for all JS,
2) to move beyond the limitations of RequireJS and CommonJS requires
parsing, and that is
Le 26/06/2012 16:44, David Bruant a écrit :
Also relevant to this thread, post on the same topic by Isaacs
(node.js lead) : http://blog.izs.me/post/25906678790/on-es-6-modules
Furthermore, |let| already gives us destructuring assignment. If a
module exports a bunch of items, and we want several
The linked blog post is a very rough cut of where my thoughts are on
the subject. Expect changes and cleanup. It does not represent a
fully-baked (or even half-baked) idea, but more like a general
direction.
I expect to clean it up and propose something at least half-baked to
this list soon,
Hi Isaac,
I share some of your concerns as well. I like the idea of import just
returning an object, which can be destructured using let. I also like the
idea of eliminating the import * syntax. However, I think that dynamic
exports (export expression) might not be as useful as it seems.
In
On 26 June 2012 16:45, Kevin Smith khs4...@gmail.com wrote:
Hi Isaac,
I share some of your concerns as well. I like the idea of import just
returning an object, which can be destructured using let. I also like the
idea of eliminating the import * syntax. However, I think that dynamic
Le 26/06/2012 20:54, Isaac Schlueter a écrit :
The linked blog post is a very rough cut of where my thoughts are on
the subject. Expect changes and cleanup. It does not represent a
fully-baked (or even half-baked) idea, but more like a general
direction.
I expect to clean it up and propose
On 26 June 2012 18:36, Aymeric Vitte vitteayme...@gmail.com wrote:
Node.js's way is good, except the transitive dependency issue mentioned
in your post which in some cases indeed can cause problems.
Does Node not handle transitive dependencies per CommonJS Modules/1.0?
What I find bad (1)
On Tue, Jun 26, 2012 at 4:48 PM, Wes Garland w...@page.ca wrote:
On 26 June 2012 18:36, Aymeric Vitte vitteayme...@gmail.com wrote:
Node.js's way is good, except the transitive dependency issue mentioned
in your post which in some cases indeed can cause problems.
Does Node not handle
Posted here:
http://tagneto.blogspot.ca/2012/06/es-modules-suggestions-for-improvement.html
Some of it is a retread of earlier feedback, but some of it may have
been lost in my poor communication style. I did this as a post instead
of inline feedback since it is long, it has lots of hyperlinks
74 matches
Mail list logo
