On Thu, Jun 26, 2014 at 4:50 PM, Russell Leggett russell.legg...@gmail.com
wrote:
//import a single named export
import foo from bar;
//import multiple named exports
import foo, baz from bar;
//alias an imported named export
import foo as fooAlias from bar;
On Fri, Jun 27, 2014 at 3:41 AM, Michał Gołębiowski m.go...@gmail.com
wrote:
On Thu, Jun 26, 2014 at 4:50 PM, Russell Leggett
russell.legg...@gmail.com wrote:
//import a single named export
import foo from bar;
//import multiple named exports
import foo, baz from bar;
On Thu, Jun 19, 2014 at 4:04 PM, David Herman dher...@mozilla.com wrote:
On Jun 19, 2014, at 3:31 AM, Michał Gołębiowski m.go...@gmail.com wrote:
Compare these 3 forms of importing all the module lodash bindings to
an object _:
```js
var _ = require(lodash); // Node
import * as _ from
On Fri, Jun 27, 2014 at 9:44 AM, Russell Leggett russell.legg...@gmail.com
wrote:
No, that example would be:
import mkdirp as mkdir;
Its actually shorter than node.
But in current proposal the module object cannot be a function from what I
understand. So you'd have to create a named
Some observations:
* I think the 'import * as x' syntax for module imports is not an
improvement, for at least two reasons:
- It raises the expectation that you can actually write 'import *
from' (as already noted in this thread).
- It removes the syntactic marker for binding a module
- Either we think real modules are an improvement, and checking is
important. Then the model and the syntax should be consistent about
that. Moreover, checking needs to consistently apply, no matter how a
module and its components are defined or accessed.
- Or we come to the conclusion
My opinion is that CommonJS and AMD work today and will continue to work
into the future so we should optimize for the ideal looking forward, not
backward case when adding to the language. Loader will still be
overload-able and since both CommonJS and AMD require a library today it
seems
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Kevin
Smith
The second option, on the other hand, will take us back to the drawing board
and I don't see how we can do that within the ES6 timeline.
We should not be concerned about timeframe in terms of what official Ecma
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Matthew
Robb
My opinion is that CommonJS and AMD work today and will continue to work into
the future so we should optimize for the ideal looking forward, not
backward case when adding to the language.
While this is a
We should not be concerned about timeframe in terms of what official Ecma
spec revision modules land in. ES has moved to a train model, recognizing
that it's more important when features ship in browsers than when Ecma
publishes a copyrighted document containing the features.
Fair enough -
In the currently specced design of classes, the fact that the creation step and
the initialisation step of built-in object may be separated by arbitrary user
code is thought to be problematic.
Jason proposed a @@new behaviour in replacement of @@create that would avoid
the issue [1]. Here is a
+1
On Fri, Jun 27, 2014 at 6:39 AM, Matthew Robb matthewwr...@gmail.com
wrote:
My opinion is that CommonJS and AMD work today and will continue to work
into the future so we should optimize for the ideal looking forward, not
backward case when adding to the language. Loader will still be
+1
Yeah - obviously +1 from me as well.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Fri, Jun 27, 2014 at 3:52 AM, Michał Gołębiowski m.go...@gmail.com
wrote:
On Fri, Jun 27, 2014 at 9:44 AM, Russell Leggett
russell.legg...@gmail.com wrote:
No, that example would be:
import mkdirp as mkdir;
Its actually shorter than node.
But in current proposal the module
var mkdirp = require('mkdirp');
Exactly. In ES, you would see this:
import { mkdrip } from mkdirp;
Python has a somewhat similar module system, and import-renaming is the
exception, not the rule. Also, I've never heard anyone complain about
having to know the name of a module
Ok, so can I just ask a serious question. I looked at the mkdirp library,
and in their own documentation, they use:
var mkdirp = require('mkdirp');
So let's say in the new world order, no default exports, this is a named
export mkdirp. Is it *really* that bad a thing to just use the
On Fri, Jun 27, 2014 at 10:11 AM, Kevin Smith zenpars...@gmail.com wrote:
var mkdirp = require('mkdirp');
Exactly. In ES, you would see this:
import { mkdrip } from mkdirp;
Python has a somewhat similar module system, and import-renaming is the
exception, not the rule. Also,
I wrote up a gist summarizing the different proposals that were being
tossed around, it mainly says the same things as Andreas, just not as well
https://gist.github.com/calvinmetcalf/5d9a88abaa9fe094e960\
On Fri, Jun 27, 2014 at 10:02 AM, Kevin Smith zenpars...@gmail.com wrote:
+1
Yeah -
Please do the following substitutions in my message:
* created-but-initialised → created-but-not-initialised
* an ordinary object → an object (i.e. a value of type Object) that is not a
Non-Constructed Object (2x)
—Claude
Le 27 juin 2014 à 15:56, Claude Pache claude.pa...@gmail.com a écrit :
This might be a good time to bring up this old thing:
https://gist.github.com/domenic/1ab3f0daa7b37859ce43
At the time Yehuda and I put it together, we were much younger and more naive,
but upon cursory review it seems not-horrible. It gives up mutable bindings but
retains
My opinion is that CommonJS and AMD work today and will continue to work
into the future so we should optimize for the ideal looking forward, not
backward case when adding to the language.
I think this statement points the way to something that we haven't yet
discussed.
A general question
On Fri, Jun 27, 2014 at 9:07 AM, Andreas Rossberg rossb...@google.com
wrote:
- It removes the syntactic marker for binding a module identifier.
That is problematic because (a) module identifiers come with extra
static checks on their uses (or so I thought, see below), and it is
(b) future
I'm echoing Kevin here.
I'd hope ES6 modules would offer me, a programmer working on large
complex JS web apps, something more then what CommonJS/AMD offers.
I work with codebases of 1K+ JS classes, 200K+ LOC and with many
dependecies that are updated frequently.
When our teams update depedencies
On 27 June 2014 18:36, C. Scott Ananian ecmascr...@cscott.net wrote:
On Fri, Jun 27, 2014 at 9:07 AM, Andreas Rossberg rossb...@google.com
wrote:
- It removes the syntactic marker for binding a module identifier.
That is problematic because (a) module identifiers come with extra
static
On Fri, Jun 27, 2014 at 3:17 PM, Andreas Rossberg rossb...@google.com
wrote:
I think you are missing the central problem. If imports/exports are to
be statically checked, then module bindings, their exports, and their
uses have to be statically recognisable and analysable. That prohibits
On 27 June 2014 17:32, Kevin Smith zenpars...@gmail.com wrote:
So to me the path forward is clear: we keep real modules, axe the default
feature, and take a temporary hit of dissatisfaction from existing users so
that we can expand the JS user base.
Note that the other half of my argument was
import {f, g, h} from url
f(); g(); h()
or
module M from url
M.f(); M.g(); M.h()
These should be freely interchangeable -- the programmer shouldn't
need to pick between getting import checking but polluting the scope
and making uses less readable, or the other way round. The
On 27 June 2014 21:26, C. Scott Ananian ecmascr...@cscott.net wrote:
On Fri, Jun 27, 2014 at 3:17 PM, Andreas Rossberg rossb...@google.com
wrote:
I think you are missing the central problem. If imports/exports are to
be statically checked, then module bindings, their exports, and their
uses
On Fri, Jun 27, 2014 at 3:34 PM, Andreas Rossberg rossb...@google.com
wrote:
All this means is that there will effectively be two different module
systems, and in practice, every module provider has to pick one. Which
is a problem, not a solution.
...this is why I've been arguing strongly
The module author has the choice to re/structure his module to allow lazy
binding/checking *iff the users demand*.
All this means is that there will effectively be two different module
systems, and in practice, every module provider has to pick one. Which
is a problem, not a solution.
On 27 Jun 2014 21:29, Andreas Rossberg rossb...@google.com wrote:
Note that the other half of my argument was that real modules are
only worth the complexity when they provide checking _consistently_.
That is, it shouldn't matter whether I write
import {f, g, h} from url
f(); g(); h()
Andreas, I hope you're not just getting my hopes up with the
possibility of checking ModuleImports too.
That would be great. I was disappointed that they weren't originally.
Making
module fs from 'fs';
fs.readFile(...);
and
import {readFile} from 'fs';
equivalent in terms of
32 matches
Mail list logo
