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
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
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
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
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
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
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
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
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
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
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
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
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.
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
14 matches
Mail list logo
