Re: A plan to help TC39 become more open up to community contributions and participations

Maybe also a factor: JS has changed a huge amount in a short time. Developers, browsers, tools need to catch up, digest the changes, decide what real problems remain. We have enough new for now. On Fri, May 27, 2016 at 7:42 AM, Kevin Smith wrote: > Thanks for pointing out

Re: ES6 import directive

Hi Lorenzo, almost all of your requests are covered by a related imperative loader API, http://whatwg.github.io/loader/#loader-import This work is not quite complete and thus not well described but your goals will be met with this API. jjb On Thu, Jan 7, 2016 at 8:30 AM, Lorenzo Ferrara

Re: treated as a module if ...

On Sun, Jul 5, 2015 at 8:46 AM, Domenic Denicola d...@domenic.me wrote: To be explicit: there is no way to look at a string of JavaScript text and tell whether it should be treated as a module or a script. In many instances the same string can be treated as both. The decision is made by

Re: Promise sub-class: super((resolve, reject) = this) ?

On Wed, Jun 3, 2015 at 1:27 AM, Benjamin Gruenaum benjami...@gmail.com wrote: Am I missing something obvious in `super((resolve, reject) = this)` ? First of all, it makes perfect sense for `this` not work work before super has been called - and it has not been called yet. Rather than

Re: import ModuleSpecifier

This same claim could be made about every item in ECMAScript. Implementation variation in ModuleSpecifiers is no different from variation in the allowed keywords, character set, or really anything a developer types. Failing to specify this aspect of the language makes no sense to this developer

Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?

Correct, ES6 has no plans for a bundling solution and the whatwg group working on the loader has not proposed one. Nevertheless bundling solution is easier to build and specify. In ES6, given a root module you can compute the (static) dependency graph as the basis for creating a bundle. The

Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?

Sorry, but what I read was not an explanation but rather a hope that HTTP/2 would magically solve this problem. I'm all for HTTP/2 solving this. But so far I've not heard or read anything to back up the idea. Will HTTP/2 make multiple round trips, one for each level of the dependency tree,

Re: Are ES6 modules in browsers going to get loaded level-by-level?

On Thu, Apr 16, 2015 at 11:16 PM, medikoo medikoo+mozilla@medikoo.com wrote: Thanks for clarifications, Still after reading your comments I have a feeling that providing ES6 modules to browsers (efficient way) will be much more cumbersome and tricky than it is to provide CJS ones now.

Re: Are ES6 modules in browsers going to get loaded level-by-level?

On Thu, Apr 16, 2015 at 1:22 PM, Domenic Denicola d...@domenic.me wrote: From: John Barton [mailto:johnjbar...@google.com] But the push scenario in your first paragraph would not use the cache either. Yeah, that's what I was alluding to with the most naïve comment. one or the other has

Re: Are ES6 modules in browsers going to get loaded level-by-level?

On Thu, Apr 16, 2015 at 12:18 PM, Domenic Denicola d...@domenic.me wrote: Is there any mean in sight, that will allow us to serve them as fast as we can serve hundreds of bundled and minimized CJS modules now? Yes. Any browser which implements the ES6 module loader (none of them right

Re: include 'foo/index.js' or include 'foo'?

The following solution has worked very well for us: import './foo/index.js'; means resolve './foo/index.js' relative to the importing file. All of the rest mean look up 'foo' in the developer's mapping of names, replacing 'foo' with a path that is then used to resolve the import. To be sure

Re: Any news about the `module` element?

=module console.log( shoud be 12: + ++window.sequence); /script Allen Sent from my iPhone On Dec 20, 2014, at 3:01 PM, John Barton johnjbar...@google.com wrote: On Sat, Dec 20, 2014 at 10:54 AM, Matthew Robb matthewwr...@gmail.com wrote: On Sat, Dec 20, 2014 at 1:50 PM, Caridy

Re: Any news about the `module` element?

On Fri, Dec 19, 2014 at 8:55 PM, caridy car...@gmail.com wrote: inline... On Dec 19, 2014, at 3:21 PM, James Burke jrbu...@gmail.com wrote: ... * How does dynamic loading work in a web worker? In general, how does dynamic loading work when there is no DOM. think about this as nodejs

Re: Any news about the `module` element?

On Sat, Dec 20, 2014 at 10:54 AM, Matthew Robb matthewwr...@gmail.com wrote: On Sat, Dec 20, 2014 at 1:50 PM, Caridy Patino car...@gmail.com wrote: what make you think this proposal implies blocking? ​I think he was reading your examples using require() and thinking you were suggesting

Re: What would a 1JS-friendly strict mode look like?

1JS strict mode would look like modules. jjb ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules that don't exist

Traceur reports such errors like this: // Error: File not found 'feature/Modules/resources/no_such_file.js' // Error: Specified as ./resources/no_such_file.js. // Error: Imported by feature/Modules/Error_InvalidModuleDeclaration.module.js. // Error: Normalizes to

Re: Importing modules that don't exist

, nice job On Fri, Nov 21, 2014 at 3:37 PM, John Barton johnjbar...@google.com wrote: Traceur reports such errors like this: // Error: File not found 'feature/Modules/resources/no_such_file.js' // Error: Specified as ./resources/no_such_file.js. // Error: Imported by feature/Modules

Re: A new ES6 draft, Rev28

On Tue, Oct 14, 2014 at 11:04 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: This includes the major work items from the September TD39 meeting. Changes include: - Removed loader pipeline and Reflect.Loader API (functionality being transfered to sperate specification) Any

Re: what makes a file a module?

On Sun, Oct 19, 2014 at 2:23 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: It is implementation dependent how it is determined whether an individual file will be parsed as a Script or as a Module. Axel alluded to a possible HTML extension that could be used to distinguish modules from

Re: dynamic synchronous import

and executed synchronously. Forcing folks to never use any module for code that needs to be inline seems like a bad turn. On Fri, Sep 26, 2014 at 1:44 PM, John Barton johnjbar...@google.com wrote: Theoretically you can use System.normalize() and System.get() to lookup a module by name

Re: dynamic synchronous import

no. On Fri, Sep 26, 2014 at 8:12 AM, Konstantin Ikonnikov ikokos...@gmail.com wrote: Can I import module dynamically, but synchronously? Example for common js ```js var moduleName = 'foo'; var foo = require(moduleName); ``` In es6 draft I found that ModuleSpecifier must be a

Re: dynamic synchronous import

, John Barton johnjbar...@google.com wrote: no. On Fri, Sep 26, 2014 at 8:12 AM, Konstantin Ikonnikov ikokos...@gmail.com wrote: Can I import module dynamically, but synchronously? Example for common js ```js var moduleName = 'foo'; var foo = require(moduleName); ``` In es6 draft I

Re: Idea for Strawman: separate the core standard library itself into modules

A way to start would add new built-ins only in modules. jjb On Mon, Sep 22, 2014 at 12:15 PM, Isiah Meadows impinb...@gmail.com wrote: Transitioning the native API to modules is more of a proposed long term goal of this proposal. It'll take years to fully realize. On Sep 22, 2014 3:10 PM,

Re: import script -- .esm

I work on Traceur's loader and participate in the loader discussions on es-discuss. I find the lack of engagement by the developers of the loader disheartening. The long, painful, sometimes contentious discussions about classes yielded an outstanding design that works well. Is the loader on track

import script -- .esm

A couple of months ago I tried out the suggestion by Yehuda Katz to use import syntax with special module specifiers to mean parse-as-script, do evaluate but do not produce a module. The implementation worked well and now I want to put a version of this idea into Traceur. As soon as I started I

Re: import script -- .esm

On Wed, Sep 10, 2014 at 9:35 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Sep 10, 2014, at 9:28 AM, Matthew Robb wrote: As soon as the language decided it would have a differentiation for modules vs scripts then it seems only natural that it should also specify at least some

Re: import script -- .esm

On Wed, Sep 10, 2014 at 10:07 AM, Guy Bedford guybedf...@gmail.com wrote: The question of whether a file is a module or script is the same problem as to whether a module is ES6 or AMD or CommonJS. Moving it to the extension makes as much sense as having every CommonJS module written as

Re: import script -- .esm

On Wed, Sep 10, 2014 at 11:02 AM, Guy Bedford guybedf...@gmail.com wrote: On 10 September 2014 19:18, John Barton johnjbar...@google.com wrote: In NodeJS, this can be through `package.json` properties which inform what module format the package is. In the browser, this could be a header

Re: import script -- .esm

On Wed, Sep 10, 2014 at 10:33 AM, Brendan Eich bren...@mozilla.org wrote: Matthew Robb wrote: I don't see why they have to? Traceur should be used as a build time tool that ultimately runs in legacy mode. Only REAL modern ES6 module implementations would run in this other world. Basically

Re: import script -- .esm

On 10 September 2014 20:14, John Barton johnjbar...@google.com wrote: On Wed, Sep 10, 2014 at 11:02 AM, Guy Bedford guybedf...@gmail.com wrote: On 10 September 2014 19:18, John Barton johnjbar...@google.com wrote: In NodeJS, this can be through `package.json` properties which inform

Re: ... A community is writing the spec...

You can find lots of information about design discussions by reading the ecmascript wiki, for example: http://wiki.ecmascript.org/doku.php?id=harmony:proxies. The other good resource is the past posts to this list and the meeting minutes, http://esdiscuss.org/. In general, the content that is

Re: `this` inside modules

Was this decision reversed? I don't see Reflect.global in the new spec. online. jjb On Mon, Jun 9, 2014 at 10:08 AM, Caridy Patino car...@gmail.com wrote: My point: if 'this' is not global in modules, then ES6 must have an alternative way to name the global object. Yes, we covered that

instantiate() deps list

The Loader instantiate() function is described: https://people.mozilla.org/~jorendorff/es6-draft.html#sec-reflect.loader.prototype.instantiate Based on that description I assume that the 'deps' property returned by instantiate() meant dependencies that would be loaded by the loader. That is, one

Re: Bundling vs sending serialized dependency graph

On Thu, Aug 21, 2014 at 8:37 AM, C. Scott Ananian ecmascr...@cscott.net wrote: On Thu, Aug 21, 2014 at 11:00 AM, John Barton johnjbar...@google.com wrote: Finally, it would be ideal if we could also adjust those dependencies on the fly, since if we're reflecting dependencies described

Re: Bundling vs sending serialized dependency graph

On Thu, Aug 21, 2014 at 1:55 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 21 Aug 2014, John Barton wrote: ... more misunderstanding about bundles skipped... Let's give upon discussing bundles and pursue your dependency list scheme. I don't think it should be particularly complex

Re: Referencing modules loaded by HTML Imports.

On Tue, Aug 19, 2014 at 4:22 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 18 Aug 2014, John Barton wrote: I think we could also imagine that such an import declaration could be used without the HTML Import declaration. The fetch() call will ask for baseURL/foo/b.js and the server will say

Re: Changing dependencies during the load process.

On Wed, Aug 20, 2014 at 3:23 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 20 Aug 2014, John Barton wrote: The reverse case, where a img depends on a script, is not a use case. Why not? What if the image has an onmouseover handler that calls an API function defined

Re: Referencing modules loaded by HTML Imports.

wrote: Would there be any problems treating the html import as a virtual module itself. Giving all scripts inside the sub document the module context object as its this binding? Then to do any additional loading you'd need to do this.import(). On Aug 18, 2014 6:56 PM, John Barton johnjbar

Re: Importing modules inside HTML imports

On Mon, Aug 18, 2014 at 12:57 AM, Anne van Kesteren ann...@annevk.nl wrote: On Sun, Aug 17, 2014 at 8:52 PM, John Barton johnjbar...@google.com wrote: The argument goes like this: we all want secure Web pages, we can't secure Web pages that allow inline scripts, therefore we have to ban

Re: Importing modules inside HTML imports

On Mon, Aug 18, 2014 at 8:02 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Aug 18, 2014 at 4:57 PM, John Barton johnjbar...@google.com wrote: So you are claiming that CSP no longer restricts inline scripts and that the various online docs are incorrect? Or only that the server

Referencing modules loaded by HTML Imports.

On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson i...@hixie.ch wrote: To avoid overly spamming the list I've coallesced my responses to various threads over the weekend into this one e-mail. I really think this makes the discussion more difficult to follow and certainly more difficult to

Changing dependencies during the load process.

On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 15 Aug 2014, John Barton wrote: On Fri, Aug 15, 2014 at 3:41 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 15 Aug 2014, John Barton wrote: The ES Loader does not maintain a dependency tree. It maintains

Re: Importing modules inside HTML imports

, no perf penalty, and it complies with CSP restrictions, the best of both worlds! /caridy On Aug 18, 2014, at 11:35 AM, John Barton johnjbar...@google.com wrote: On Mon, Aug 18, 2014 at 8:02 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Aug 18, 2014 at 4:57 PM, John Barton

Re: Modules and dependencies found during the load (before instantiation)

On Mon, Aug 18, 2014 at 10:55 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 13 Aug 2014, Ian Hickson wrote: One of the problems I'm running into when it comes to trying to integrate ES6 modules with HTML and new HTML-based dependency features is the way that I can't tell ES about

Re: Changing dependencies during the load process.

On Mon, Aug 18, 2014 at 2:00 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 18 Aug 2014, John Barton wrote: On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 15 Aug 2014, John Barton wrote: On Fri, Aug 15, 2014 at 3:41 PM, Ian Hickson i...@hixie.ch wrote

Re: Referencing modules loaded by HTML Imports.

On Mon, Aug 18, 2014 at 2:06 PM, Ian Hickson i...@hixie.ch wrote: Now, in the main page, you reference the HTML import: link rel=import href=foo.html Now how would you refer to the modules? We can't have #b refer to it, since the scope of IDs is per-document,

Re: Changing dependencies during the load process.

On Mon, Aug 18, 2014 at 5:32 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 18 Aug 2014, John Barton wrote: ... But in the case of image tags we already know exactly which image the HTML depends upon. But other elements might depends on the img, and that we don't know. (For example

Re: Importing modules inside HTML imports

On Sat, Aug 16, 2014 at 10:22 AM, Brendan Eich bren...@mozilla.org wrote: Yes -- inline scripts, like document.write, the drive-in, disco, and Fortran, will never die. More things I don't suggest investing effort in. /be Anne van Kesteren wrote: On Sat, Aug 16, 2014 at 2:46 AM, John

Re: Importing modules inside HTML imports

On Sun, Aug 17, 2014 at 10:08 AM, Brendan Eich bren...@mozilla.org wrote: John Barton wrote: On Sat, Aug 16, 2014 at 10:22 AM, Brendan Eich bren...@mozilla.org mailto:bren...@mozilla.org wrote: Yes -- inline scripts, like document.write, the drive-in, disco, and Fortran

Re: Importing modules inside HTML imports

On Sun, Aug 17, 2014 at 11:14 AM, Rick Waldron waldron.r...@gmail.com wrote: On Sunday, August 17, 2014, John Barton johnjbar...@google.com wrote: On Sun, Aug 17, 2014 at 10:08 AM, Brendan Eich bren...@mozilla.org wrote: John Barton wrote: On Sat, Aug 16, 2014 at 10:22 AM, Brendan

Re: Modules and dependencies known before the load

On Fri, Aug 15, 2014 at 9:43 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 14 Aug 2014, John Barton wrote: But since the only way the client can know that it needs a.js and jquery.js is if the server tells it [...] There's at least four ways this can happen: - the server tells

Re: Modules and dependencies known before the load

On Fri, Aug 15, 2014 at 2:43 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 15 Aug 2014, John Barton wrote: On Fri, Aug 15, 2014 at 9:43 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 14 Aug 2014, John Barton wrote: But since the only way the client can know that it needs a.js

Re: Changing dependencies

The ES Loader does not maintain a dependency tree. It maintains a table of names-modules. So when the @import rules mutate, just load the new names. Any new modules will be traversed for dependents and new name-modules entries will be created. Well, assuming you figure out how to integrate CSS

Re: Changing dependencies

On Fri, Aug 15, 2014 at 3:41 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 15 Aug 2014, John Barton wrote: The ES Loader does not maintain a dependency tree. It maintains a table of names-modules. Maybe I'm misunderstanding the ES6 loader spec. What's the Load Record [[Dependencies

Re: Importing modules inside HTML imports

On Fri, Aug 15, 2014 at 3:06 PM, Ian Hickson i...@hixie.ch wrote: Suppose you have an HTML import foo.html that declares two modules: script type=module id=a ... /script script type=module id=b ... /script As we noted in another thread, Web devs no longer control servers. And servers

Re: Modules and dependencies known before the load

On Thu, Aug 14, 2014 at 2:20 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 13 Aug 2014, John Barton wrote: On Wed, Aug 13, 2014 at 3:52 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 13 Aug 2014, John Barton wrote: On Wed, Aug 13, 2014 at 2:59 PM, Ian Hickson i...@hixie.ch wrote

Re: Modules and dependencies known before the load

Your example will just work if you just use script type=module import a; // ... /script When this module is compiled the other two will be loaded and compiled. jjb On Wed, Aug 13, 2014 at 2:59 PM, Ian Hickson i...@hixie.ch wrote: One of the problems I'm running into when it

Re: Modules and dependencies known before the load

On Wed, Aug 13, 2014 at 3:52 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 13 Aug 2014, John Barton wrote: On Wed, Aug 13, 2014 at 2:59 PM, Ian Hickson i...@hixie.ch wrote: Suppose a page has this markup: script type=module id=jquery href=jquery.js whenneeded/script script

Re: Understanding the 'normalize' Loader hook

See the implemention in es6-module-loader: https://github.com/ModuleLoader/es6-module-loader/blob/master/lib/system.js#L117 In traceur we have different code that passes the same tests. The tests: https://github.com/google/traceur-compiler/blob/master/test/unit/runtime/System.js We would map

Re: Understanding the 'normalize' Loader hook

On Tue, Aug 12, 2014 at 2:45 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 12 Aug 2014, John Barton wrote: See the implemention in es6-module-loader: https://github.com/ModuleLoader/es6-module-loader/blob/master/lib/system.js#L117 Ah, fascinating. So basically: - normalize does

Re: Understanding the 'normalize' Loader hook

On Tue, Aug 12, 2014 at 3:26 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 12 Aug 2014, John Barton wrote:... (only if the last segment is part of the path part of the URL and doesn't contain a .?). No such restriction is applied in our code. Sure. What do we want for the default Web

Re: Loader vs ES6 Classes

Related issue that had come up in discussions I've had off this list: is it likely that the spec will constrain the constructor arguments of custom Loader classes to match the arguments of Reflect.Loader? For my part I was surprised that this might be a possibility. jjb

Re: Loader vs ES6 Classes

f you read the Loader source carefully you can see that Jason fixed the Loader to support inheritance. But his fix does not allow classes to inherit the platform's loading behavior. That behavior is given in options properties passed to instances. By defining the system loader as an instance of a

Re: Loader vs ES6 Classes

As far as I can tell you are basically arguing that simple Loader hooks don't need object state. Of course that is true. And sure we can write code that carefully and cleverly avoids using 'this'. Why? ES6 added classes because this is often the clearest way to structure more complex systems. In

Re: Loader vs ES6 Classes

Neither example binds 'this' assuming the current Loader implementation, so no object state. Although maybe you are saying your example ought to work, then we agree ;-) On Mon, Aug 4, 2014 at 7:47 AM, Axel Rauschmayer a...@rauschma.de wrote: On Aug 4, 2014, at 16:33 , John Barton johnjbar

Re: Loader vs ES6 Classes

IMO a better design would have each platform subclass Loader, eg SystemLoader extends Loader and System (or 'system' if we decide to suddenly come to our senses) would be an instance of SystemLoader. SystemLoader would define the hook functions and custom Loader classes would extend SystemLoader

Re: Loader vs ES6 Classes

On Mon, Aug 4, 2014 at 1:50 PM, Jason Orendorff jason.orendo...@gmail.com wrote: The design as it stands doesn't specify the system loader or its class. It's a platform-specific detail. Yes, but ES should say a couple of things to get everyone on the same page, eg that the system loader

Re: Loader vs ES6 Classes

The System object is global, so depends is the answer to all such questions. On Mon, Aug 4, 2014 at 2:24 PM, Calvin Metcalf calvin.metc...@gmail.com wrote: Would the System object for a module loaded with a sub classed System be the sub classed one or the original one? IMO a better design

Loader vs ES6 Classes

Since I guess not too many developers work with ES6 and the Loader object, here is some feedback: the Loader callback design does not play well with ES6 classes. The Loader takes 'options', an object with function properties like normalize, locate, and fetch. If you pass a literal object with

Re: Loader locate/fetch/translate/instantiate API

Ok thanks, I see that this was added and I did not notice. (I think this kind of creeping overspecification annoying but inevitable I suppose). jjb On Wed, Jul 30, 2014 at 7:20 AM, Juan Ignacio Dopazo jdop...@yahoo-inc.com wrote: I don't have an answer, but the metadata property of the

Re: Loader locate/fetch/translate/instantiate API

The spec seems inconsistent about the metadata property. The define() function of Loader accepts options.metadata: --- 26.3.3.2Reflect.Loader.prototype.define ( name, source [ , options ] ) ... 8. Let metadata be GetOption(options, metadata). 9. ReturnIfAbrupt(metadata). 10. If metadata is

Loader locate/fetch/translate/instantiate API

The Loader hook callbacks all have an API defined like: Reflect.Loader.prototype.locate ( loadRequest ) My interpretation of this description was that the callback provider should expect the same loadRequest object in to reappear during the load pipeline and furthermore, this being JavaScript,

Re: Re: Quantifying Default Exports

On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford guybedf...@gmail.com wrote: In Brian's case we actually need default exports. This is because the dynamic loader can't pick up the code he has written right now in ES6. This is how he is loading a NodeJS module in ES6: module minimist from

Re: Re: Quantifying Default Exports

module. This is the same method we have for AMD compilations at the moment, which seems to have been working well. On 21 July 2014 10:17, John Barton johnjbar...@google.com wrote: On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford guybedf...@gmail.com wrote: In Brian's case we

Re: System as a SystemLoader class

Why not something more like: class RemappingLoader extends Reflect.Loader { constructor(hooks, baseURL, paths) { super(hooks); //... } fetch(load) { // .. } } Reflect.global.System = new RemappingLoader(Reflect.global.System, process.cwd() + '/', {'*': '*.js' }); The main

Re: System as a SystemLoader class

that but really this is ES6: can't we do better? jjb - Matthew Robb On Mon, Jul 14, 2014 at 1:53 PM, John Barton johnjbar...@google.com wrote: Why not something more like: class RemappingLoader extends Reflect.Loader { constructor(hooks, baseURL, paths) { super(hooks

include

In the module system we issue import {foo} from 'foo'; and the Loader computes an address, say foo.js, fetches the resource and compiles it. If the content of foo.js has no dependencies, it is evaluated, then the importer is evaluated. Yay! Now suppose that foo.js defines a global value. Oh

Re: include

...@cs.indiana.edu wrote: Why not: import {} from 'foo'; or import * as f from 'foo'; This is assuming that there are no other desired exports -- if there are, then the case is even easier. Sam On Mon, Jul 14, 2014 at 8:37 PM, John Barton johnjbar...@google.com wrote: In the module

Re: Asynchronous Module Initialize

On Wed, Jul 9, 2014 at 1:57 PM, Jussi Kalliokoski jussi.kallioko...@gmail.com wrote: ... I proposed (it was less of a proposal though, more an idea or an example to spur better ideas) that we had a single dynamic exportable per each module, and that could be an object, function, undefined

Loader.parse ?

In https://people.mozilla.org/~jorendorff/es6-draft.html#sec-instantiatesucceeded-instantiateresult-functions , 15.2.4.5.3 InstantiateSucceeded(instantiateResult) Functions The step number 4 reads: - If instantiateResult is undefined, then Let body be the result of parsing load.[[Source]],

Re: Re: ModuleImport

On Thu, Jul 3, 2014 at 2:31 AM, Jussi Kalliokoski jussi.kallioko...@gmail.com wrote: Tools like Traceur can support it for an easier migration path since they already have diverged from ES.next anyway with all the annotations (for which, off topic, I haven't seen even a proposal here yet)

Re: ModuleImport

This seems like a bit too many issues, so let me just correct one (important) one. On Wed, Jul 2, 2014 at 2:09 PM, Jussi Kalliokoski jussi.kallioko...@gmail.com wrote: On Wed, Jul 2, 2014 at 7:09 PM, John Barton johnjbar...@google.com wrote: Now, I know there are people that think

Re: ModuleImport

Let me try to restate my request for clear information on the advantages of module bindings vs module object architectures. The import syntax already allows pre-execution tools to collect every module that will be accessed by a root dependent module (including some that may not be used). This

Re: ModuleImport

On Mon, Jun 30, 2014 at 12:00 PM, Kevin Smith zenpars...@gmail.com wrote: What's not clear is the advantage of module bindings form for modules. When the world of possibilities opens up, what specific things will I see there? I think I'm following you now. So let's pose the question like

Re: ModuleImport

Thanks Kevin. I'm going to challenge your list below, but I hope you don't take it negatively. I want the case for the module system to be as strong as possible. On Sat, Jun 28, 2014 at 11:51 AM, Kevin Smith zenpars...@gmail.com wrote: Static checking of imports and exports has well-known

Re: ModuleImport

On Sat, Jun 28, 2014 at 3:58 PM, Kevin Smith zenpars...@gmail.com wrote: Static checking will be limited anyway. If you want to go this way you should use typescript. That's the point that I'm trying to make, shops will choose other languages that provide more static information. We should

Re: ModuleImport

On Sat, Jun 28, 2014 at 9:03 AM, Kevin Smith zenpars...@gmail.com wrote: Static checking on exported members feels odd. Static checking of imports and exports has well-known advantages and would help the long-term viability of the language. Enumerating these specific advantages would

Re: ModuleImport

+1 On Fri, Jun 27, 2014 at 6:39 AM, Matthew Robb matthewwr...@gmail.com wrote: My opinion is that CommonJS and AMD work today and will continue to work into the future so we should optimize for the ideal looking forward, not backward case when adding to the language. Loader will still be

Re: Default exports, without explicit syntactic support

On Thu, Jun 26, 2014 at 7:39 AM, Axel Rauschmayer a...@rauschma.de wrote: // my-class.js export class MyClass { constructor() { ... } method() { ... } } // use-class.js import { MyClass } from my-class.js; You do have redundancy in `my-class.js` and,

Re: ModuleImport

// I have a module named `foo`. // I don't care what `foo` is. // Including whether or not its a namespace. // I need make no promises about identifier `foo`. import {bar} from './foo'; On Wed, Jun 25, 2014 at 12:52 PM, C. Scott Ananian ecmascr...@cscott.net wrote: On Wed, Jun 25, 2014 at 2:59

Re: Loader Hooks

Guy Bedford's es6-module-loader follows the Loader spec closely. I just refactored it to create a function call `parse(load) - deps`: https://github.com/ModuleLoader/es6-module-loader/blob/master/lib/loader.js#L389 This location in the pipeline is pretty much where you suggest. I think I've

Re: debugging modules

On Tue, Jun 24, 2014 at 12:53 PM, Guy Bedford guybedf...@gmail.com wrote: If it is a tools problem, it becomes a much more complex problem. Firstly note that the promise isn't rejecting, it is resolving correctly. That is if I have a module X: X.js throw this module throws; Then:

Re: TC39 vs the community

On Fri, Jun 20, 2014 at 6:42 AM, Domenic Denicola dome...@domenicdenicola.com wrote: Can you develop these particular accusations? Why would TC39 have priorities that don't align with the needs of developers? especially on modules which are clearly one of the most awaited feature as far as

Re: TC39 vs the community

On Fri, Jun 20, 2014 at 2:03 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: I am trying to stay outside this discussion as much as I can but there is a specific sentence that I'd like to understand: On Fri, Jun 20, 2014 at 8:39 AM, John Barton johnjbar...@google.com wrote

Re: ModuleImport

ES6 already has what you want: _Named Exports_: export var foo = 1; _Single Export Object_: export var moduleName = { foo: 1, bar: function() {} }; _Single Export Function_: export function fName() { } And even cooler, the syntax for import is uniform, import {foo} from

Re: ModuleImport

On Fri, Jun 20, 2014 at 4:17 PM, Ron Buckton rbuck...@chronicles.org wrote: From: John Barton [mailto:johnjbar...@google.com] Sent: Friday, June 20, 2014 3:48 PM ES6 already has what you want: _Named Exports_: export var foo = 1; _Single Export Object_: export var

Re: ModuleImport

Sorry to be dense, but I would appreciate more elaboration of this sentence: On Thu, Jun 19, 2014 at 3:40 AM, Axel Rauschmayer a...@rauschma.de wrote: This is a key sentence in David’s proposal: “ES6 favors the single/default export style, What is the single/default export style? If I

Re: ModuleImport

On Thu, Jun 19, 2014 at 10:48 AM, Axel Rauschmayer a...@rauschma.de wrote: On Jun 19, 2014, at 16:17 , John Barton johnjbar...@google.com wrote: Sorry to be dense, but I would appreciate more elaboration of this sentence: On Thu, Jun 19, 2014 at 3:40 AM, Axel Rauschmayer a...@rauschma.de

Re: ES6 modules (sorry...)

. Unfortunately, there isn't a good delta compression solution yet but I have hopes that SDCH might be made more general and standard. On Mon, Jun 16, 2014 at 4:54 PM, John Barton johnjbar...@google.com wrote: On Mon, Jun 16, 2014 at 4:49 PM, caridy car...@gmail.com wrote: I thought

Re: ES6 modules (sorry...)

On Sun, Jun 15, 2014 at 8:32 PM, Axel Rauschmayer a...@rauschma.de wrote: I apologize for this email, but I still don’t understand the current module design. ... **Single-export modules.** Still missing is support for single-export modules, which could be added as follows (the keyword

  1   2   >