Re: ES Modules: suggestions for improvement

On Wed, Jun 27, 2012 at 2:21 PM, Sam Tobin-Hochstadt wrote: > On Wed, Jun 27, 2012 at 3:37 PM, James Burke wrote: >> On Wed, Jun 27, 2012 at 11:56 AM, Sam Tobin-Hochstadt >> wrote: >>> Then we can use the module like this: >>> >>>    System.load("add_blaster", function(ab) { return ab.go(4,5);

Re: ES Modules: suggestions for improvement

On 27 June 2012 17:40, Sam Tobin-Hochstadt wrote: > What request do you send to ask for multiple modules? We send a request like /methods/modules?root=pathto/mystuff&id=/sha256&id=/auth/password The client canonicalizes each CommonJS dependency to its full (canonical) path and tells the server

Re: ES Modules: suggestions for improvement

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 > be

Re: ES Modules: suggestions for improvement

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" wrote: >>> >>> let * = Math; >>> >>> This is dynamic scoping. The difference between import * an

Re: ES Modules: suggestions for improvement

On Wed, Jun 27, 2012 at 5:29 PM, Wes Garland wrote: > On 27 June 2012 17:21, Sam Tobin-Hochstadt 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 t

Re: ES Modules: suggestions for improvement

On 27 June 2012 17:21, Sam Tobin-Hochstadt 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 localStorage, or

Re: ES Modules: suggestions for improvement

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

Re: ES Modules: suggestions for improvement

On Wed, Jun 27, 2012 at 3:37 PM, James Burke wrote: > On Wed, Jun 27, 2012 at 11:56 AM, Sam Tobin-Hochstadt > 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: >>

Re: ES Modules: suggestions for improvement

System.load("http://mylib.com/lib.js";, function(mod) { return mod.do_stuff(); } ) Since this is async, it might be worthwhile considering more complex examples (loading multiple libs => nesting or async libs or promises?). Here's another example, constructing and installing a module at r

Re: ES Modules: suggestions for improvement

On 27 June 2012 15:45, Kevin Smith 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 from CommonJ

Re: ES Modules: suggestions for improvement

On Wed, Jun 27, 2012 at 11:51 AM, David Herman 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 local > vari

Re: ES Modules: suggestions for improvement

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 existi

Re: ES Modules: suggestions for improvement

> > 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 ma

Re: ES Modules: suggestions for improvement

> > 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 in

Re: ES Modules: suggestions for improvement

On Wed, Jun 27, 2012 at 11:56 AM, Sam Tobin-Hochstadt 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); > >

Re: ES Modules: suggestions for improvement

> > 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) Doct

Re: ES Modules: suggestions for improvement

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 'this'

Re: Modules: execute deps, modify, execute (was Re: ES Modules: suggestions for improvement)

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

Re: Modules: execute deps, modify, execute (was Re: ES Modules: suggestions for improvement)

On Wed, 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 detectio

Re: ES Modules: suggestions for improvement

On Tue, Jun 26, 2012 at 2:54 PM, Isaac Schlueter 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 four cr

Re: ES Modules: suggestions for improvement

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

Re: Internationalization: Additional values in API

Replies below. Norbert On Jun 26, 2012, at 16:02 , Mark Davis ☕ wrote: > On Tue, Jun 26, 2012 at 3:22 PM, Norbert Lindenberg > wrote: >> - The options properties style, currencyDisplay, minimumIntegerDigits, >> minimumFractionDigits, maximumFractionDigits, minimumSignificantDigits, and >>

Re: Modules: execute deps, modify, execute (was Re: ES Modules: suggestions for improvement)

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 the

Re: Implicitly escaped $ (or not) in quasis?

On 27 June 2012 15:59, Allen Wirfs-Brock wrote: > var messageWithMSGSub = Msg`${USER_INPUT}`; //The value of > messageWithMsgSub is the result of calling Msg. > > Here, Msg, is a application or library provided quasi substitution handler > function. Think about it as the DSL compiler. In this

Re: ES Modules: suggestions for improvement

> "For security, the Loader object could be frozen with Object.freeze to > prevent additional changes." > => This is not enough. People shouldn't have to opt-in for security, > mostly because they don't do it. I woud call for security by default here > and having "import " call the built-in Loader.

Re: Modules: execute deps, modify, execute (was Re: ES Modules: suggestions for improvement)

On Wed, Jun 27, 2012 at 9:47 AM, James Burke 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 world. I hope for

Re: ES Modules: suggestions for improvement

On Wed, Jun 27, 2012 at 11:15 AM, Isaac Schlueter 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 >

Re: ES Modules: suggestions for improvement

On Wed, Jun 27, 2012 at 9:02 PM, David Herman wrote: > On Jun 27, 2012, at 11:00 AM, Jussi Kalliokoski wrote: > > On Wed, Jun 27, 2012 at 8:43 PM, David Herman wrote: > >> >> >> http://blog.safeshepherd.com/23/how-one-missing-var-ruined-our-launch/ >> > > I don't see how that's at all related to

Re: ES Modules: suggestions for improvement

> 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 pen

Re: ES Modules: suggestions for improvement

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 fil

Re: ES Modules: suggestions for improvement

On Jun 27, 2012, at 11:00 AM, Jussi Kalliokoski wrote: > On Wed, Jun 27, 2012 at 8:43 PM, David Herman 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 this. Becaus

Re: ES Modules: suggestions for improvement

On Wed, Jun 27, 2012 at 8:43 PM, David Herman wrote: > On Jun 27, 2012, at 10:32 AM, Isaac Schlueter wrote: > > On Wed, Jun 27, 2012 at 9:39 AM, Brendan Eich wrote: > > var foo = 42; > > ... foop ... > > > throws at runtime in ES1-5 if evaluation reaches the foop use, and (if you > > wrap a modu

Re: ES Modules: suggestions for improvement

> > 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 ina

Re: ES Modules: suggestions for improvement

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 o

Re: ES Modules: suggestions for improvement

On Jun 27, 2012, at 10:32 AM, Isaac Schlueter wrote: > On Wed, Jun 27, 2012 at 9:39 AM, Brendan Eich 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 global foop p

Re: ES Modules: suggestions for improvement

On Wed, Jun 27, 2012 at 9:39 AM, Brendan Eich 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 (if you > wrap a

Modules: execute deps, modify, execute (was Re: ES Modules: suggestions for improvement)

On Wed, Jun 27, 2012 at 8:46 AM, Isaac Schlueter wrote: > Re: Conditional Importing > > Only allowing `import` at the top level sounds like an ok idea, but > I'm not so sure it's necessary.  Consider the current require() style: > > if (some_rare_condition()) { >  foo = require('foo') > } > > In r

Re: ES Modules: suggestions for improvement

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

Re: ES Modules: suggestions for improvement

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 JS

Re: ES Modules: suggestions for improvement

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 ex

Re: ES Modules: suggestions for improvement

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 of

Re: Implicitly escaped $ (or not) in quasis?

On Jun 27, 2012, at 1:49 AM, gaz Heyes wrote: > On 26 June 2012 17:19, Allen Wirfs-Brock wrote: > I'm working on incorporating quasis into the ES6 draft and there is an issue > I want to discuss: > > In the wiki proposal[1] $ is used as the prefix for substitutions that may > be of two form

Re: fail-fast object destructuring

Ultimately, I'd like to have both: - irrefutable matching: - refutable matching: One is a syntactic convenience for selection only, the other for selection plus structural tests (actually: behavioral interface tests, see below). Both have their uses. This suggests having pattern syntax modifiers

Re: ES Modules: suggestions for improvement

> > 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

Re: Implicitly escaped $ (or not) in quasis?

On 27 June 2012 12:38, Brendan Eich wrote: > You assume a developer will assume something. We need evidence. > > Lots of languages, e.g. CoffeeScript after Ruby, or bash after the Bourne > shell (sh), use embedded expressions in ${...} or #{...} brackets in > distinguished string (e.g., double-qu

Re: Implicitly escaped $ (or not) in quasis?

gaz Heyes wrote: On 27 June 2012 10:06, Brendan Eich > wrote: What's the difference between `lit1 ${exp1} lit2 ${exp2} lit3` and sprintf("lit1 %s lit2 %s lit3", exp1, exp2) A list of variables would have to appear outside the backticks somehow

Re: ES Modules: suggestions for improvement

Le 27/06/2012 01:48, Wes Garland a écrit : What I find bad (1) is the need of VMs, let's take node.js's one, it's calling c++ stuff, calling itself js's stuff, and at the end things are coming back to js (with some imperfections like node.js's VM not binding things correctly in

Re: Implicitly escaped $ (or not) in quasis?

On 27 June 2012 10:06, Brendan Eich wrote: > What's the difference between > > `lit1 ${exp1} lit2 ${exp2} lit3` > > and > > sprintf("lit1 %s lit2 %s lit3", exp1, exp2) > A list of variables would have to appear outside the backticks somehow like the earlier example using a function call. If no

Re: ES Modules: suggestions for improvement

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. That

Re: ES Modules: suggestions for improvement

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) : http://blog.izs.me/post/25906678790/on-es

Re: ES Modules: suggestions for improvement

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

Re: Implicitly escaped $ (or not) in quasis?

gaz Heyes wrote: On 26 June 2012 17:19, Allen Wirfs-Brock > wrote: I'm working on incorporating quasis into the ES6 draft and there is an issue I want to discuss: In the wiki proposal[1] $ is used as the prefix for substitutions that may be of two

Re: ES Modules: suggestions for improvement

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 assi

Re: Implicitly escaped $ (or not) in quasis?

On 26 June 2012 17:19, Allen Wirfs-Brock wrote: > I'm working on incorporating quasis into the ES6 draft and there is an > issue I want to discuss: > > In the wiki proposal[1] $ is used as the prefix for substitutions that > may be of two forms: >`xyz$foo 1234` //$foo substitues the va

Re: ES Modules: suggestions for improvement

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 items