Le 08/04/2013 15:48, Anne van Kesteren a écrit :
> On Mon, Apr 8, 2013 at 2:43 PM, Rick Waldron <waldron.rick at gmail.com> wrote:
>> On Mon, Apr 8, 2013 at 9:37 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
>>> So modules have not yet landed in ES6, but are planned. I also heard
>>> they will have a pretty dramatic impact on APIs. When is TC39 planning
>>> to bring that discussion here?
>> Can you be more specific?
> I'd need to have specifics first and they're not in the ES6 draft.
I'll try to start with some point I have in mind, others will complete 
as necessary.

 From what I know, there are 2 parts:
1) module syntax [1]
2) module loader API [2]

As far as 1) the "import" semantics part might need some attention in 
relation to URLs and how they are resolved (relative to the JS resource 
url? document url?). There is probably a need for some module name 
resolution binding to hook with the Fetch algorithm for cases like:
     import "http://www.mywebsite.com/myScript.js"

I don't think 2) will affect the platform; it's its own objects with 
their own semantics.

>> What are your concerns?
> I'd like to evaluate the impact of ES6 modules on web platform APIs.
> How we'll need to accommodate for them down the road.
It might be interesting to start adding new APIs not as global 
properties or properties in navigator, but rather as built-in modules 
(I'm not entirely clear on how these are defined/listed/feature 
detected/what's the import syntax for them).
Maybe have WebIDL interpret any interface as a module or something of 
this kind in an attempt to steer JS devs away from globals. I imagine it 
might not be possible as I phrased it, but it feels worth investigating.
All of that might have to wait until major browser makers all have some 
support for ES6 modules.

I have most certainly forgotten some points, but that can be a start.
Anne, are there other points you anticipate could need some discussion?

David

[1] http://wiki.ecmascript.org/doku.php?id=harmony:modules
[2] http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders

> I'd need to have specifics first and they're not in the ES6 draft.

I'll try to start with some point I have in mind, others will complete as necessary.

From what I know, there are 2 parts:

1. [module syntax](http://wiki.ecmascript.org/doku.php?id=harmony:modules)
2. [module loader API](http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders)

As far as 1) the "import" semantics part might need some attention in relation to URLs and how they are resolved (relative to the JS resource url? document url?). There is probably a need for some module name resolution binding to hook with the Fetch algorithm for cases like:

```js
import "http://www.mywebsite.com/myScript.js"
```

I don't think 2) will affect the platform; it's its own objects with their own semantics.

> I'd like to evaluate the impact of ES6 modules on web platform APIs.
> How we'll need to accommodate for them down the road.

It might be interesting to start adding new APIs not as global properties or properties in navigator, but rather as built-in modules (I'm not entirely clear on how these are defined/listed/feature detected/what's the import syntax for them).

Maybe have WebIDL interpret any interface as a module or something of this kind in an attempt to steer JS devs away from globals. I imagine it might not be possible as I phrased it, but it feels worth investigating.  All of that might have to wait until major browser makers all have some support for ES6 modules.

I have most certainly forgotten some points, but that can be a start.  Anne, are there other points you anticipate could need some discussion?