Re: Re: Rationale for dropping ModuleImport syntax?
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 are a great idea. I'd also like to echo the comments that ES6 modules seem well designed, looking forward to native implementations. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Rationale for dropping ModuleImport syntax?
On Thu, Jun 12, 2014 at 3:46 AM, Brian Di Palma off...@gmail.com 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 exclusively uses
multiple exports.
Its lack will force existing module maintainers to export as small a set as
possible - likely either a single identifier - so that they can service the
existing identifier-as-namespace convention CommonJS forces.
Given that there's no real syntactic difference between single identifier
export and default export, I would imagine default export would win since
then you get: `import _ from 'underscore'` instead of import { _ } from
'underscore'`.
Related to some other comments made in this thread, I think static
verification errors are a great idea.
I'd also like to echo the comments that ES6 modules seem well
designed, looking forward to native implementations.
I definitely agree. I think the semantics and specification are awesome.
And having syntax at all is *huge* for tooling and aot/static compilers.
The ModuleImport syntax can be bikeshedded until the cows come home. It's
not important (to me). What's important is that there is syntax to get at
its functionality, not imperative code.
IMO the only real issue is the tight coupling between syntax used to import
and syntax used to export. Why as a module consumer should the module
author's choice dictate which syntax I'm forced to use? And why as a
module author should the syntax my users want to use dictate how I have to
export my module? If syntaxes were decoupled, ModuleImport could go away
and we wouldn't lose the functionality, it would simply be `import _ from
'underscore'`.
I don't think it's outlandish, the possibility that a large enough portion
of the community will decide on a single import syntax as best, and
network effects will result in it going from best to only.
-c
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Rationale for dropping ModuleImport syntax?
On Thu, Jun 12, 2014 at 6:37 PM, Chris Toshok tos...@gmail.com wrote:
On Thu, Jun 12, 2014 at 3:46 AM, Brian Di Palma off...@gmail.com 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 exclusively uses multiple
exports.
Its lack will force existing module maintainers to export as small a set as
possible - likely either a single identifier - so that they can service the
existing identifier-as-namespace convention CommonJS forces.
Given that there's no real syntactic difference between single identifier
export and default export, I would imagine default export would win since
then you get: `import _ from 'underscore'` instead of import { _ } from
'underscore'`.
I can see that being a valid path for certain modules to take. I'm not
sure large utility packages will be as prevelant in future though.
Once we have a standard module system it seems just as likely that
these packages might break apart somewhat.
There seems no reason to load all of underscore into a module for just
one or two functions.
The underscore web page itself divides the functions http://underscorejs.org/
We should also be wary of building cases on code from Parsers, I
believe the unstructured switch statement was designed for parsers.
It didn't turn out to be an optimal design for routine programming though.
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.
Related to some other comments made in this thread, I think static
verification errors are a great idea.
I'd also like to echo the comments that ES6 modules seem well
designed, looking forward to native implementations.
I definitely agree. I think the semantics and specification are awesome.
And having syntax at all is *huge* for tooling and aot/static compilers.
The ModuleImport syntax can be bikeshedded until the cows come home. It's
not important (to me). What's important is that there is syntax to get at
its functionality, not imperative code.
The imperative code given as an alternative is ugly, it probably won't
gain many users.
IMO the only real issue is the tight coupling between syntax used to import
and syntax used to export. Why as a module consumer should the module
author's choice dictate which syntax I'm forced to use? And why as a module
author should the syntax my users want to use dictate how I have to export
my module? If syntaxes were decoupled, ModuleImport could go away and we
wouldn't lose the functionality, it would simply be `import _ from
'underscore'`.
I like the idea but I can't imagine many people would welcome yet more
changes to ES modules.
I don't think it's outlandish, the possibility that a large enough portion
of the community will decide on a single import syntax as best, and
network effects will result in it going from best to only.
-c
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
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 couldn't, that would also allow time for bikeshedding the syntax. It could be added later, but to turn the question around: why should it be dropped? It has been part of the design for a very long time, it's currently used by many people working in the ES6 space, and it meets a semantic need. If you want to drop a feature this late in the game, then you need to show that it's one of the following: 1. Buggy 2. A footgun 3. Not useful 4. Future-hostile I don't see that it meets any of those requirements, do you? Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Re: Rationale for dropping ModuleImport syntax?
That's a very good set of criteria, Kevin; I think it helps frame the discussion. I think the argument is that, based on experience with the transpilers, it is a footgun, with related to people not knowing when to use which. This has been exacerbated by transpilers not correctly distinguishing `import x from y` and `module x from y`, and the complete lack of stable usable documentation for the spec. In my opinion, people have not had enough experience with a documented, stable, spec, or with non-buggy transpilers, so trying to argue that it is a footgun in the current environment should not hold much weight. There are also arguments that it is not useful, but I think those arguments are specious for the reasons I've already been over earlier. From: es-discuss es-discuss-boun...@mozilla.org on behalf of Kevin Smith zenpars...@gmail.com Sent: Thursday, June 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 couldn't, that would also allow time for bikeshedding the syntax. It could be added later, but to turn the question around: why should it be dropped? It has been part of the design for a very long time, it's currently used by many people working in the ES6 space, and it meets a semantic need. If you want to drop a feature this late in the game, then you need to show that it's one of the following: 1. Buggy 2. A footgun 3. Not useful 4. Future-hostile I don't see that it meets any of those requirements, do you? Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Rationale for dropping ModuleImport syntax?
On Thu, Jun 12, 2014 at 8:50 PM, Kevin Smith zenpars...@gmail.com 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 syntax. It could be added later, but to turn the question around: why should it be dropped? It has been part of the design for a very long time, it's currently used by many people working in the ES6 space, and it meets a semantic need. If you want to drop a feature this late in the game, then you need to show that it's one of the following: 1. Buggy 2. A footgun 3. Not useful 4. Future-hostile I don't see that it meets any of those requirements, do you? I have no strong opinions either way. I don't feel it's any of those things. The argument that was given was that people were confused by it and were using it like an `import` statement. I said to Eric via Twitter that if people were building incorrect compilers and modules then they will eventually learn the error of their assumptions. To me the argument didn't seem that strong, the native implementations will be correct and people will correct their broken code. I'm not supporting the removal. I simply don't think it's a catastrophe. Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Rationale for dropping ModuleImport syntax?
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 object On Thu, Jun 12, 2014 at 8:50 PM, Kevin Smith zenpars...@gmail.com 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 syntax. It could be added later, but to turn the question around: why should it be dropped? It has been part of the design for a very long time, it's currently used by many people working in the ES6 space, and it meets a semantic need. If you want to drop a feature this late in the game, then you need to show that it's one of the following: 1. Buggy 2. A footgun 3. Not useful 4. Future-hostile I don't see that it meets any of those requirements, do you? I have no strong opinions either way. I don't feel it's any of those things. The argument that was given was that people were confused by it and were using it like an `import` statement. I said to Eric via Twitter that if people were building incorrect compilers and modules then they will eventually learn the error of their assumptions. To me the argument didn't seem that strong, the native implementations will be correct and people will correct their broken code. I'm not supporting the removal. I simply don't think it's a catastrophe. Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Rationale for dropping ModuleImport syntax?
On Thu, Jun 12, 2014 at 10:07 PM, Calvin Metcalf calvin.metc...@gmail.com 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 see the logic in doing that. Did they not wonder why there were two ways to accomplish the exact same thing? As I said, I didn't find the reasoning compelling. 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 object On Thu, Jun 12, 2014 at 8:50 PM, Kevin Smith zenpars...@gmail.com 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 syntax. It could be added later, but to turn the question around: why should it be dropped? It has been part of the design for a very long time, it's currently used by many people working in the ES6 space, and it meets a semantic need. If you want to drop a feature this late in the game, then you need to show that it's one of the following: 1. Buggy 2. A footgun 3. Not useful 4. Future-hostile I don't see that it meets any of those requirements, do you? I have no strong opinions either way. I don't feel it's any of those things. The argument that was given was that people were confused by it and were using it like an `import` statement. I said to Eric via Twitter that if people were building incorrect compilers and modules then they will eventually learn the error of their assumptions. To me the argument didn't seem that strong, the native implementations will be correct and people will correct their broken code. I'm not supporting the removal. I simply don't think it's a catastrophe. Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Rationale for dropping ModuleImport syntax?
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:18 PM, Brian Di Palma off...@gmail.com wrote: On Thu, Jun 12, 2014 at 10:07 PM, Calvin Metcalf calvin.metc...@gmail.com 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 see the logic in doing that. Did they not wonder why there were two ways to accomplish the exact same thing? As I said, I didn't find the reasoning compelling. 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 object On Thu, Jun 12, 2014 at 8:50 PM, Kevin Smith zenpars...@gmail.com 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 syntax. It could be added later, but to turn the question around: why should it be dropped? It has been part of the design for a very long time, it's currently used by many people working in the ES6 space, and it meets a semantic need. If you want to drop a feature this late in the game, then you need to show that it's one of the following: 1. Buggy 2. A footgun 3. Not useful 4. Future-hostile I don't see that it meets any of those requirements, do you? I have no strong opinions either way. I don't feel it's any of those things. The argument that was given was that people were confused by it and were using it like an `import` statement. I said to Eric via Twitter that if people were building incorrect compilers and modules then they will eventually learn the error of their assumptions. To me the argument didn't seem that strong, the native implementations will be correct and people will correct their broken code. I'm not supporting the removal. I simply don't think it's a catastrophe. Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Rationale for dropping ModuleImport syntax?
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 about them as well. On Thu, Jun 12, 2014 at 5:18 PM, Brian Di Palma off...@gmail.com wrote: On Thu, Jun 12, 2014 at 10:07 PM, Calvin Metcalf calvin.metc...@gmail.com 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 see the logic in doing that. Did they not wonder why there were two ways to accomplish the exact same thing? As I said, I didn't find the reasoning compelling. 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 object On Thu, Jun 12, 2014 at 8:50 PM, Kevin Smith zenpars...@gmail.com 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 syntax. It could be added later, but to turn the question around: why should it be dropped? It has been part of the design for a very long time, it's currently used by many people working in the ES6 space, and it meets a semantic need. If you want to drop a feature this late in the game, then you need to show that it's one of the following: 1. Buggy 2. A footgun 3. Not useful 4. Future-hostile I don't see that it meets any of those requirements, do you? I have no strong opinions either way. I don't feel it's any of those things. The argument that was given was that people were confused by it and were using it like an `import` statement. I said to Eric via Twitter that if people were building incorrect compilers and modules then they will eventually learn the error of their assumptions. To me the argument didn't seem that strong, the native implementations will be correct and people will correct their broken code. I'm not supporting the removal. I simply don't think it's a catastrophe. Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Rationale for dropping ModuleImport syntax?
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 zenpars...@gmail.com 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. 2. Educate. Perhaps those of us on the list that really get modules should be writing about them as well. On Thu, Jun 12, 2014 at 5:18 PM, Brian Di Palma off...@gmail.com wrote: On Thu, Jun 12, 2014 at 10:07 PM, Calvin Metcalf calvin.metc...@gmail.com 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 see the logic in doing that. Did they not wonder why there were two ways to accomplish the exact same thing? As I said, I didn't find the reasoning compelling. 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 object On Thu, Jun 12, 2014 at 8:50 PM, Kevin Smith zenpars...@gmail.com 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 syntax. It could be added later, but to turn the question around: why should it be dropped? It has been part of the design for a very long time, it's currently used by many people working in the ES6 space, and it meets a semantic need. If you want to drop a feature this late in the game, then you need to show that it's one of the following: 1. Buggy 2. A footgun 3. Not useful 4. Future-hostile I don't see that it meets any of those requirements, do you? I have no strong opinions either way. I don't feel it's any of those things. The argument that was given was that people were confused by it and were using it like an `import` statement. I said to Eric via Twitter that if people were building incorrect compilers and modules then they will eventually learn the error of their assumptions. To me the argument didn't seem that strong, the native implementations will be correct and people will correct their broken code. I'm not supporting the removal. I simply don't think it's a catastrophe. Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Rationale for dropping ModuleImport syntax?
On Thu, Jun 12, 2014 at 5:30 PM, Kevin Smith zenpars...@gmail.com 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 adoption, I think this is probably the best option. It’s too late to reopen the discussion of import x from x changing to have syntax that better supports multiple export, and I really dislike the implications of dropping module from at this point in the process. 2. Educate. Perhaps those of us on the list that really get modules should be writing about them as well. I’d prefer *evangelizing* more than *educating*. I’d like to see more direct attempts to engage with the proponents of CommonJS and AMD to see where their comfort level is now. Some of them have prematurely written off ES6 modules (IMO), but the larger community (particularly around Node / browserify) just doesn’t understand the feature, and therefore can’t give meaningful feedback for or against it – or what should change – yet. F ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Rationale for dropping ModuleImport syntax?
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. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Rationale for dropping ModuleImport syntax?
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? The engine would then bind the import based on the
accessed export.
import a from b; a.c;
Is the same as
import {c} from b;
On Jun 12, 2014 5:38 PM, Calvin Metcalf calvin.metc...@gmail.com wrote:
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 zenpars...@gmail.com 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.
2. Educate. Perhaps those of us on the list that really get modules
should be writing about them as well.
On Thu, Jun 12, 2014 at 5:18 PM, Brian Di Palma off...@gmail.com wrote:
On Thu, Jun 12, 2014 at 10:07 PM, Calvin Metcalf
calvin.metc...@gmail.com 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 see the
logic in doing that.
Did they not wonder why there were two ways to accomplish the exact same
thing?
As I said, I didn't find the reasoning compelling.
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 object
On Thu, Jun 12, 2014 at 8:50 PM, Kevin Smith zenpars...@gmail.com
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 syntax.
It could be added later, but to turn the question around: why should
it
be
dropped? It has been part of the design for a very long time, it's
currently used by many people working in the ES6 space, and it meets a
semantic need.
If you want to drop a feature this late in the game, then you need to
show
that it's one of the following:
1. Buggy
2. A footgun
3. Not useful
4. Future-hostile
I don't see that it meets any of those requirements, do you?
I have no strong opinions either way. I don't feel it's any of those
things.
The argument that was given was that people were confused by it and
were using it like an `import` statement.
I said to Eric via Twitter that if people were building incorrect
compilers and modules then they will eventually learn the error of
their assumptions.
To me the argument didn't seem that strong, the native implementations
will be correct and people will correct their broken code.
I'm not supporting the removal. I simply don't think it's a
catastrophe.
Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
