I agree unless the properties of said object are getter-objects that return
the bound identifier from the exporting module. Of course this would
require specifying such a thing and can happen later.
What if we get rid of this "module instance object" and instead treat it as
a binding namespace? Th
> The fact that here is a distinction between the bindings from the module
> and the instance object of the module is the issue
>
But that distinction has always been central to the design. A module is a
collection of named bindings. The default thing is an optimization
feature, not the core.
___
On Thu, Jun 12, 2014 at 5:30 PM, Kevin Smith wrote:
So I think this argues for two actions:
>
> 1. Leave the syntax as-is. The "module from" syntax makes the
> distinction between getting the module instance object, and importing
> bindings from a module very clear.
>
If the goal is community a
The fact that here is a distinction between the bindings from the module
and the instance object of the module is the issue
On Jun 12, 2014 8:30 PM, "Kevin Smith" wrote:
> So I think this argues for two actions:
>
> 1. Leave the syntax as-is. The "module from" syntax makes the
> distinction bet
So I think this argues for two actions:
1. Leave the syntax as-is. The "module from" syntax makes the distinction
between getting the module instance object, and importing bindings from a
module very clear.
2. Educate. Perhaps those of us on the list that really get modules
should be writing
One unusual but interesting metric: try to find blog posts explaining
module m from 'mymodule';
vs posts explaining import. At least my attempts failed.
Basically authors who thought ES6 modules are worth explaining did not
think 'module' was worth explaining.
jjb
On Thu, Jun 12, 2014 at 2
On Thu, Jun 12, 2014 at 10:07 PM, Calvin Metcalf
wrote:
> isn't the foot gun the difference between single and multiple exports, i.e.
I thought it was imports that were being misused. People were writing
module m from 'mymodule';
m();
So they treated `module` just like `import`. I'm not sure I
isn't the foot gun the difference between single and multiple exports, i.e.
to import underscore you'd use
module _ from 'underscore'
because it is multiple methods on an object but for jquery you'd have to use
import $ from 'jquery'
because the root object is a function instead of an objec
On Thu, Jun 12, 2014 at 8:50 PM, Kevin Smith wrote:
>
>>
>> I was more wondering if there was anything preventing a module import
>> statement from being added later, if it was found to be a requirement.
>> I can't see any reason why it couldn't, that would also allow time for
>> bikeshedding the
ne 12, 2014 15:50
To: Brian Di Palma
Cc: es-discuss list
Subject: Re: Re: Rationale for dropping ModuleImport syntax?
I was more wondering if there was anything preventing a module import
statement from being added later, if it was found to be a requirement.
I can't see any reason why it c
>
> I was more wondering if there was anything preventing a module import
> statement from being added later, if it was found to be a requirement.
> I can't see any reason why it couldn't, that would also allow time for
> bikeshedding the syntax.
>
It could be added later, but to turn the question
On Thu, Jun 12, 2014 at 6:37 PM, Chris Toshok wrote:
> On Thu, Jun 12, 2014 at 3:46 AM, Brian Di Palma wrote:
>>
>> Is there anything preventing the addition of a "ModuleImport" like
>> affordance at a later stage (e.g. ES7)?
>
>
> ModuleImport is the only way (in syntax) to achieve CommonJS `req
On Thu, Jun 12, 2014 at 3:46 AM, Brian Di Palma wrote:
> Is there anything preventing the addition of a "ModuleImport" like
> affordance at a later stage (e.g. ES7)?
>
ModuleImport is the only way (in syntax) to achieve CommonJS `require`
behavior on the consumer-side when a module author exclus
Is there anything preventing the addition of a "ModuleImport" like
affordance at a later stage (e.g. ES7)?
I haven't done much development with ES6 modules but I've not found
much use for that form when I have.
Related to some other comments made in this thread, I think static
verification errors
For anyone interested in the transpiler story around the existing spec I
opened an issue here: https://github.com/google/traceur-compiler/issues/1072
- Matthew Robb
On Wed, Jun 11, 2014 at 5:43 PM, Kevin Smith wrote:
> Thanks Caridy,
>
> Please forgive my occasional hyperbole, I think es-disc
Thanks Caridy,
Please forgive my occasional hyperbole, I think es-discuss is best served
with a dash of spice now and then. : )
I agree that the current design is somewhat confusing. That's because it
represents a perfectly balanced compromise between the multi-export,
remote-binding design fav
Kevin, although I agree that ES6 modules are well-designed, I don't think
the checkpoint that we did last week was a mistake, in fact, we invited
implementers of the polyfills and transpilers to share their concerns and
questions, to help us to correct course, that's all it was.
Saying that the `m
Everyone just needs to chill out - ES6 modules are well-designed (thanks to
Sam and Dave and Andreas and maybe myself a little ; ) and they are going
to work extremely well in the field.
The message needs to be that modules are *done*. Period. (Minus some
minor cosmetic issues, perhaps.) Openi
On 11 June 2014 14:01, Matthew Robb wrote:
> On Wed, Jun 11, 2014 at 1:53 PM, John Barton
> wrote:
>
>> The Traceur project would be interested in your issues and in a
>> discussion on how to improve. Improvements are easy to try.
>> jjb
>>
>
> No matter what improvements could be made you are a
On Wed, Jun 11, 2014 at 1:53 PM, John Barton wrote:
> The Traceur project would be interested in your issues and in a discussion
> on how to improve. Improvements are easy to try.
> jjb
>
No matter what improvements could be made you are always going to have a
slower, less performant program if
The Traceur project would be interested in your issues and in a discussion
on how to improve. Improvements are easy to try.
jjb
On Wed, Jun 11, 2014 at 1:25 PM, Matthew Robb
wrote:
>
> I have been working extensively with modules in a project that will be
> going live this year. I am using tr
On Wed, Jun 11, 2014 at 4:39 PM, Domenic Denicola
wrote:
> From: es-discuss on behalf of Matthew Robb
>
>
>> Transpile aside, I don't want that performance concern. Most of the time I
>> want a real solid reference and the only way to get it as the spec stands is
>> to import something and th
From: es-discuss on behalf of Matthew Robb
> Transpile aside, I don't want that performance concern. Most of the time I
> want a real solid reference and the only way to get it as the spec stands is
> to import something and then cache it locally. Isn't that kind of crazy?
I don't know what
I have been working extensively with modules in a project that will be
going live this year. I am using traceur and I find myself often doing the
following:
module fs from "fs";
> var { readFile } = fs;
OR
> import { readFile as _readFile } from "fs";
>
var
> readFile = _readFile;
>
I
On Wed, Jun 11, 2014 at 3:41 PM, Kevin Smith wrote:
> Well, you're assuming exactly the state of affairs that this thread is
> questioning... The fact that the threat of changing things to this degree
> has dredged up such polarized opinions should indicate that we ought to be
> leaving things al
>
> I would second that. I have seen no desire for any static analysis beyond
> "this module depends on that module" and I've seen no desire for live bound
> imports.
>
I believe that viewpoint is adequately represented in the status quo. No
need to legislate other viewpoints away.
> I accept th
> I really just want single exports and destructuring of single exports...??
I would second that. I have seen no desire for any static analysis beyond
"this module depends on that module" and I've seen no desire for live bound
imports.
I accept that we're messing with a fragile consensus, bu
I've been thinking about this thread a lot the last couple days. I started
out feeling defensive of the current proposal but I think I do agree that
the idea of live bound imports is neat it's also not something I'm asking
for or planning to use in the near term. I really just want single exports
a
On Tue, Jun 10, 2014 at 5:19 AM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
> Marius Gundersen
>
> > I'd say we only support named exports, something like this:
> https://gist.github.com/mariusGundersen/88a4c5690e0
> > These and other options have been discussed on es-discuss over the past
> 2 or 3 years
>
> But back then there was no real world usage yet? Shouldn't new feedback be
> taken into account?
>
If there is new data it should definitely be considered. I just don't see
any new data right now that c
> (bikeshed: don't leave out this option for the syntax `import module from
> "underscore"`)
>
Unfortunately, this one won't work because "module" in this context is a
plain ol' identifier. AFAIK, there's no interest in making "module" a
proper keyword. (Right now it's just a contextual keyword.
(bikeshed: don't leave out this option for the syntax `import module from
"underscore"`)
On Tue, Jun 10, 2014 at 3:15 PM, Karolis Narkevičius
wrote:
> > These and other options have been discussed on es-discuss over the past
> 2 or 3 years
>
> But back then there was no real world usage yet? Sh
> These and other options have been discussed on es-discuss over the past 2
or 3 years
But back then there was no real world usage yet? Shouldn't new feedback be
taken into account?
On Tue, Jun 10, 2014 at 2:27 PM, Forbes Lindesay
wrote:
> > Please, cosmetic changes only! : )
>
>
> Fair eno
> Please, cosmetic changes only! : )
Fair enough. In that spirit, how about we keep the functionality that was
recently dropped, but fix the strange wording of it (a cosmetic change) so that
it becomes:
```js
import 'underscore' as _;
```
as has been suggested by other people. It's not
These and other options have been discussed on es-discuss over the past 2
or 3 years, but didn't win out. (I'm having trouble finding links at the
moment, unfortunately.) No new information is being presented here.
Again, the current design was a hard-earned compromise and should not be
tinkered
If we don't have a really clean and simple upgrade path for all existing users
of module systems, I can't see ES6 modules gaining widespread adoption. If
nobody objects to that core premise, we must make it easy for users and
producers of modules like underscore, as well as producers and consum
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Marius
Gundersen
> I'd say we only support named exports, something like this:
> https://gist.github.com/mariusGundersen/88a4c5690e08da0d07f6
If you do that, the real-world consequences will be even worse. Nobody (to a
first
>
>
> Agreed. Which is why I predict module makers will, at the encouragement of
> module consumers, stick to default-export only, since it is more in line
> with existing practice.
>
FWIW, I predict the opposite, but I could be wrong. A really good thing
about the current design is that it allow
On Tue, Jun 10, 2014 at 9:06 AM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
> Marius Gundersen
>
> > This will likely lead to a lot of confusion, not only for module makers
> but also for module consumers.
>
> Agre
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Marius
Gundersen
> This will likely lead to a lot of confusion, not only for module makers but
> also for module consumers.
Agreed. Which is why I predict module makers will, at the encouragement of
module consumers, stick t
On Tue, Jun 10, 2014 at 1:13 AM, Kevin Smith wrote:
>
>> ```
>> ImportClause :
>> ImportedBinding
>> ImportedBinding , NamedImports
>> NamedImports
>> ```
>>
>>
> Side topic, but this particular production:
>
> ImportClause: ImportedBinding , NamedImports
>
> needs to die an immediate
>
>
> ```
> ImportClause :
> ImportedBinding
> ImportedBinding , NamedImports
> NamedImports
> ```
>
>
Side topic, but this particular production:
ImportClause: ImportedBinding , NamedImports
needs to die an immediate death.
> Or would the default value be an object containing all th
On Mon, Jun 9, 2014 at 7:40 PM, Karolis Narkevičius
wrote:
> Why can't we have both with the same syntax?
>
> ```js
> // imports a function which is the default export
> import mkdirp from "mkdirp";
> ```
>
> and
>
> ```js
> // imports all named exports, like module used to
> import fs from "fs";
Why can't we have both with the same syntax?
```js
// imports a function which is the default export
import mkdirp from "mkdirp";
```
and
```js
// imports all named exports, like module used to
import fs from "fs";
```
On Mon, Jun 9, 2014 at 5:50 PM, Matthew Robb wrote:
> Gah.. Phone. Side-e
Gah.. Phone. Side-effects*
On Jun 9, 2014 9:47 AM, matthewwr...@gmail.com wrote:
And the as portion can be optional if all you want is import dude effects.
On Jun 9, 2014 9:42 AM, "Caridy Patino" wrote:
`import "./foo" as foo;` certainly looks nice.
On Mon, Jun 9, 2014 at 12:36 PM, Kevin Smith
And the as portion can be optional if all you want is import dude effects.
On Jun 9, 2014 9:42 AM, "Caridy Patino" wrote:
> `import "./foo" as foo;` certainly looks nice.
>
>
> On Mon, Jun 9, 2014 at 12:36 PM, Kevin Smith wrote:
>
>> IIUC, the motivation for dropping the form is that it's confus
That particular use of module-from is a little special. "@objc_internal" is a
native module. Once ejs supports enumerating multiple exports from native
modules I'll be switching that to an import-{}-from.
An example of use would be my toy test applications that consume the modules:
https://gith
On Mon, Jun 9, 2014 at 9:17 AM, Mark S. Miller wrote:
> On Mon, Jun 9, 2014 at 9:08 AM, John Barton
> wrote:
> [...]
>
> but ES6 is a class-based language: based on our experience the majority
>> of exports going forward will be classes.
>>
>
> Hi John, that sounds interesting. What more can yo
`import "./foo" as foo;` certainly looks nice.
On Mon, Jun 9, 2014 at 12:36 PM, Kevin Smith wrote:
> IIUC, the motivation for dropping the form is that it's confusing to have
> this other syntactic option which uses a different (contextual) keyword.
>
> Well, we already have this:
>
> impor
IIUC, the motivation for dropping the form is that it's confusing to have
this other syntactic option which uses a different (contextual) keyword.
Well, we already have this:
import "./foo";
which you can use when you want to load+execute but not import anything.
Is that going away? If not
> Chris, the number of exports is not relevant, and in fact, there is no way
> to export all members in one go, which aligns well with the proposal to
> remove the way to import an object with all members. check the consumers of
> the `uikit` module, and count how many of those exported methods are
Chris, the number of exports is not relevant, and in fact, there is no way
to export all members in one go, which aligns well with the proposal to
remove the way to import an object with all members. check the consumers of
the `uikit` module, and count how many of those exported methods are used
in
>
>
> but ES6 is a class-based language: based on our experience the majority
>> of exports going forward will be classes.
>>
>
> Hi John, that sounds interesting. What more can you tell us about that
> experience?
>
>
My experience also agrees with John's. It just makes sense from a
design-persp
Pirouette also has many exports per module for its bindings:
E.g.
https://github.com/toshok/pirouette/blob/master/bindings/uikit.js.
I use both import-{}-from (with many imported bindings) and module-from forms,
tending toward the former in framework code and the latter in application code.
The
On Mon, Jun 9, 2014 at 9:08 AM, John Barton wrote:
[...]
> but ES6 is a class-based language: based on our experience the majority
> of exports going forward will be classes.
>
Hi John, that sounds interesting. What more can you tell us about that
experience?
--
Cheers,
--MarkM
__
On Mon, Jun 9, 2014 at 7:51 AM, Axel Rauschmayer wrote:
> I’m assuming that people will default-export objects (for
> Underscore.js-like libraries). I’d call those pseudo-modules, because one
> would be partially working around the module system (no load-time errors!).
>
Then aren't you arguing
"esparse" used to have a module which exported a huge list of things, and
for the same reason I believe.
Basically there's an "AST" module which exports a huge list of AST
node-type classes. That module is then exported to the public interface.
https://github.com/zenparsing/esparse/blob/53566066
Traceur definitely has a lot of exports in a single module.
https://github.com/google/traceur-compiler/blob/master/src/syntax/Parser.js#L15
We do not however, use the `module` form since we want to get rid of the
extra Get (which deopts switch statements in some engines).
On Mon Jun 09 2014 at 1
My perspective here is that there are not too many modules (in nodejs) that
rely on more than a handful of exports from a particular module, we are
actively working on validating this using esprima in a large set of npm
modules. If this is true, we should be just fine with specific imports, and
for
> As an aside, it is yet to be seen whether the "default" export thing is the
> best way, or the bad part itself. We don't have the real world experience
> yet to answer that.
I’d even argue that they led to the predicament that we are currently in.
If the default export didn’t look like “the
I agree with Alex.
We can tolerate this syntactic form being dropped for now, but that doesn't
eliminate the semantic need. If the "module" contextual keyword is a
problem, then we should be able to come up with another color for the
bikeshed, e.g.:
import "foo" as foo;
As an aside, it is
I would like to see a reigning in of uses of curly braces. We already have
at least these:
1) code blocks
2) literal objects
3) destructuring
I don't like that the module syntax adds yet another. I'd like to think of
the curly braces in the module syntax as being like destructuring. That way
the m
I’m assuming that people will default-export objects (for Underscore.js-like
libraries). I’d call those pseudo-modules, because one would be partially
working around the module system (no load-time errors!).
Maybe we’ll import modules like this [^1], but that feels syntactically
inconsistent to
On Mon, Jun 9, 2014 at 6:54 AM, Axel Rauschmayer wrote:
> On the other hand, we’ll have many pseudo-modules, which is also a barrier
> against making progress later on.
>
Sorry, I don't understand what a pseudo-module is. Are you saying that the
core import/export system is not correct and that
On the other hand, we’ll have many pseudo-modules, which is also a barrier
against making progress later on.
On Jun 9, 2014, at 15:51 , John Barton wrote:
> If the 'module' form is left out, it can be added later. If the 'module' form
> is left in, it can never be removed.
> jjb
>
>
> On Mo
If the 'module' form is left out, it can be added later. If the 'module'
form is left in, it can never be removed.
jjb
On Mon, Jun 9, 2014 at 6:39 AM, Axel Rauschmayer wrote:
> Isn't the problem, though, that default-exporting an object prevents
> static checking? It feels like an abuse of this
>> Isn't the problem, though, that default-exporting an object prevents static
>> checking? It feels like an abuse of this feature to me.
>
> We don't have static checking today, so this is no loss to me.
If I understand ES6 modules correctly, importing a non-exported identifier
gives you a loa
From: Axel Rauschmayer [mailto:a...@rauschma.de]
> Isn't the problem, though, that default-exporting an object prevents static
> checking? It feels like an abuse of this feature to me.
We don't have static checking today, so this is no loss to me. (And ES6 modules
give enough benefits over ES5
Why can't we have this?
```js
// when only default exports are used
// import that one function
import mkdirp from "mkdirp";
// when only named exports are used
// import it like a module
import fs from "fs";
// when both named and default exports are used
// this imports the default export
impo
> Sent: Monday, June 9, 2014 02:39
> To: es-discuss list
> Subject: Rationale for dropping ModuleImport syntax?
>
> Context:
> https://gist.github.com/caridy/eefb9b104874465d4e1c#1-moduleimport-syntax-importdeclaration
>
> ```js
> module foo from "foo"; // drop
x unused by
popular libraries.
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Axel
Rauschmayer
Sent: Monday, June 9, 2014 02:39
To: es-discuss list
Subject: Rationale for dropping ModuleImport syntax?
Context:
https://gist.github.com/caridy/eefb9b104874465d4e1c#1-moduleimport-s
Context:
https://gist.github.com/caridy/eefb9b104874465d4e1c#1-moduleimport-syntax-importdeclaration
```js
module foo from "foo"; // drop this
import bar from "bar";
```
I’m seeing the following contra against dropping ModuleImport syntax:
> Contra: without a way to access the module object, it
72 matches
Mail list logo
