Calvin Metcalf (2014-01-30T15:49:46.000Z)
forgot to hit replay all

On Thu, Jan 30, 2014 at 10:25 AM, Kevin Smith <zenparsing at gmail.com> wrote:

> [Did you mean to reply all?]
>
> ```js
>> var projs = [
>>     import "./projections/merc",
>>     import "./projections/longlat"
>> ];
>> ```
>>
>
> That idea was last discussed on the list two or three years ago.  The
> problem is that you are placing strange and novel placement restrictions on
> expression forms, which is sure to cause more confusion than it's worth.
>  What about cases like:
>
>     var x = f || import "blah";
>
> Should that be different than this?
>
>     var x = import "blah" || f;
>
> The current module design is straightforward and clean.  Have you tried
> doing any coding with them?
>

yes I've coded with them via ember app kit's grunt es6 module transpiler
thingy, the syntax was significantly more complex and verbose than commonjs
and we ended up switching over to browserify/commonjs.

    var x = f || import "blah";
> Should that be different than this?
>     var x = import "blah" || f;

if we have static linking (which imho is great, not complaining about it,
seriously good work guys) then those should act in the same way, what I'm
really suggesting is probably more like sugar for,

```js
var x = f || import "blah";
//becomes ->
import "blah" as _temp;
var x = f || _temp;
```

similar to export default which didn't change anything behind the scenes.


On Thu, Jan 30, 2014 at 9:28 AM, Kevin Smith <zenparsing at gmail.com> wrote:

> var projs = [
>>   require('./projections/merc'),
>>
>>
>>   require('./projections/longlat')
>> ];
>>
>>
> With ES6 modules, you might do something like this:
>
>     import merc from "./projections/merc";
>     import longlat from "./projections/longlat";
>
>     var projs = [merc, longlat];
>
> Or if you're importing the modules themselves:
>
>     module merc from "./projectsions/merc";
>     module longlat from "./projectsions/longlat";
>
>     var projs = [merc, longlat];
>
>
>> is there a reason [import] can't be an expression which evaluates to
>> either an object with all the [exports] or the default export when it's
>> used as an AssignmentExpression (I think I'm using that one right).
>>
>>
> Yes.  ES6 modules are "statically linked", meaning that all of the
> non-local (imported) bindings are resolved *before the module begins
> executing*.  It's an important distinction.
>
> Because of this difference, you can expect usage patterns to turn out
> somewhat different from the "require" patterns we are used to seeing in
> node.
>
>


-- 
-Calvin W. Metcalf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140130/b1465215/attachment.html>
domenic at domenicdenicola.com (2014-02-04T20:56:22.144Z)
forgot to hit replay all

On Thu, Jan 30, 2014 at 10:25 AM, Kevin Smith <zenparsing at gmail.com> wrote:

> [Did you mean to reply all?]
>
>> ```js
>> var projs = [
>>     import "./projections/merc",
>>     import "./projections/longlat"
>> ];
>> ```
>
> That idea was last discussed on the list two or three years ago.  The
> problem is that you are placing strange and novel placement restrictions on
> expression forms, which is sure to cause more confusion than it's worth.
>  What about cases like:
>
>     var x = f || import "blah";
>
> Should that be different than this?
>
>     var x = import "blah" || f;
>
> The current module design is straightforward and clean.  Have you tried
> doing any coding with them?
>

yes I've coded with them via ember app kit's grunt es6 module transpiler
thingy, the syntax was significantly more complex and verbose than commonjs
and we ended up switching over to browserify/commonjs.

    var x = f || import "blah";

> Should that be different than this?
>
>     var x = import "blah" || f;

if we have static linking (which imho is great, not complaining about it,
seriously good work guys) then those should act in the same way, what I'm
really suggesting is probably more like sugar for,

```js
var x = f || import "blah";
//becomes ->

import "blah" as _temp;
var x = f || _temp;
```

similar to export default which didn't change anything behind the scenes.