On Saturday, July 19, 2014 1:53 PM, Brian Di Palma off...@gmail.com wrote:
When an npm package exports a named identifier it's trivial to use it
in an ES6 module.
import {
parse,
print
} from 'recast';
When on the other hand it sets its export on `module.exports` default
exports
It's using traceur and building the modules to CJS, the project uses
other non transpiled CJS modules.
The only thing traceur could do here is compile the imports into a
check for the named export `default` and use that if it exists.
If it doesn't then simply return the CJS module object.
Here
similar discussion at systemjs
https://github.com/systemjs/systemjs/issues/131 which boils down to if a
CJS module imports an ES6 module that has a key named default, what should
the default behavior be.
On Mon, Jul 21, 2014 at 10:05 AM, Brian Di Palma off...@gmail.com wrote:
It's using
Which shows the how the backward compatability argument for default
export/imports doesn't stand up.
If you want to import `module.exports` then use the the `module` form
if you want named imports use the named form.
Default import/exports are generating nothing more then complexity,
confusion
that won't help if module.exports is a function
Overall the import/exports semantics of es6 and cjs modules would be
compatible if mixing named and default exports was prohibited, but the
ability to have both is hard to represent in cjs modules.
On Mon, Jul 21, 2014 at 10:24 AM, Brian Di Palma
On Mon, Jul 21, 2014 at 3:31 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
that won't help if module.exports is a function
That's exactly what `minimist` is, works just fine.
https://github.com/substack/minimist/blob/master/index.js
Overall the import/exports semantics of es6 and cjs
I have a CommonJS module which exports a single function
```js
//cj.js
module.exports = function (){}
```
If I was to transform it into an ES6 module the best way to do so currently
it so use a default export
```js
//cj2es6.js
export default function () {}
```
now say I want to import those
Making named and default exports be mutually exclusive would mean that you
could treat default export like module.exports.
Or just drain the swamp and remove default exports, rather than fighting
these alligators.
___
es-discuss mailing list
On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
I have a CommonJS module which exports a single function
```js
//cj.js
module.exports = function (){}
```
If I was to transform it into an ES6 module the best way to do so currently
it so use a default export
(woops hit reply instead of reply all)
Because the `function mainThing(){}` might already have a method named
helper or, more likely, the named export is something like call or bind.
On Mon, Jul 21, 2014 at 12:06 PM, Brian Di Palma off...@gmail.com wrote:
On Mon, Jul 21, 2014 at 4:16 PM,
Yep, that makes sense. Highly unlikely but still possible and could
cause issues.
No doubt you could complicate your compiler to deal with these edge
cases but why force that?
Yet more problems with default imports/exports. This feature doesn't
seem worth its cost.
On Mon, Jul 21, 2014 at 5:21
Interoperability should not be a decisive factor here, we have fallen into
that trap before, the conclusion was to let Loader to handle those cases
rather than trying to drive it from the perspective of the module syntax.
Let's focus on what is best and what makes sense for the ES Modules, and
In Brian's case we actually need default exports. This is because the
dynamic loader can't pick up the code he has written right now in ES6.
This is how he is loading a NodeJS module in ES6:
module minimist from 'minimist';
In ES6 this means give me the Module object with getters to the
On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford guybedf...@gmail.com wrote:
In Brian's case we actually need default exports. This is because the
dynamic loader can't pick up the code he has written right now in ES6.
This is how he is loading a NodeJS module in ES6:
module minimist from
On Tue, 10 Jun 2014, Ian Hickson wrote:
On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:
By an ECMAScript Environment (and this is what Ecma-262 defines,
although it doesn't actually use that name) I mean a heap of
ECMAScript objects (and related values) that may directly reference
Yes this is a bug that can be fixed at the compiler level. As you say we
can generate a wrapper when loading a non-ES6 module in ES6:
newModule({
default: require('minimist')
})
We then conditionally add this wrapper based on detecting if the import is
an ES6 module. This is the same method we
bugs.emcascript.org will be down for maintenance starting at 6:00 PM PDT July
21, 2014 ( 22 July 2014, 01:00 UTC).
We're getting an updated version of bugzilla and other server updates.
Hopefully it will only take a few hours.___
es-discuss mailing
8.5 Initialization step 4 says Push newContext onto the execution context
stack, and step 8 calls NextTask. 8.4.2 NextTask suspends the running
execution context in step 2, then in step 3 asserts The execution context
stack is now empty. However, I can't find anything in the prose around
From: Boris Zbarsky [mailto:bzbar...@mit.edu]
On 6/24/14, 9:51 AM, Domenic Denicola wrote:
I'd be interested in collaborating on designing such a language extension.
I think I would too; I'm just not sure about availability.
For posterity, [I tried to replicate this functionality using
On Jul 21, 2014, at 11:23 AM, Ian Hickson wrote:
8.5 Initialization step 4 says Push newContext onto the execution context
stack, and step 8 calls NextTask. 8.4.2 NextTask suspends the running
execution context in step 2, then in step 3 asserts The execution context
stack is now empty.
Is this meant to prevent people tampering with them?
In that case, global.Symbol should also be non-configurable non-writable
or something. Otherwise you can just redefine it.
-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
On Mon, 21 Jul 2014, Ian Hickson wrote:
On Tue, 10 Jun 2014, Ian Hickson wrote:
On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:
By an ECMAScript Environment (and this is what Ecma-262 defines,
although it doesn't actually use that name) I mean a heap of
ECMAScript objects (and
On Mon, 21 Jul 2014, Allen Wirfs-Brock wrote:
On Jul 21, 2014, at 11:23 AM, Ian Hickson wrote:
8.5 Initialization step 4 says Push newContext onto the execution
context stack, and step 8 calls NextTask. 8.4.2 NextTask suspends the
running execution context in step 2, then in step 3
On Jul 21, 2014, at 10:49 AM, Ian Hickson wrote:
On Tue, 10 Jun 2014, Ian Hickson wrote:
On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:
By an ECMAScript Environment (and this is what Ecma-262 defines,
although it doesn't actually use that name) I mean a heap of
ECMAScript objects (and
It doesn't seem an issue that requires the ES6 module spec to have
something like default imports though.
The compiler could output
`
newModule({
default: require('minimist')
})
`
and importers could do
`import {default as minimist} from 'minimist';`
Or you could have
`
newModule({
On Jul 21, 2014, at 1:29 PM, Ian Hickson wrote:
On Mon, 21 Jul 2014, Allen Wirfs-Brock wrote:
On Jul 21, 2014, at 11:23 AM, Ian Hickson wrote:
8.5 Initialization step 4 says Push newContext onto the execution
context stack, and step 8 calls NextTask. 8.4.2 NextTask suspends the
running
Because somebody thought it was a good idea ;-) ...
On Jul 21, 2014, at 1:04 PM, Boris Zbarsky wrote:
Is this meant to prevent people tampering with them?
In that case, global.Symbol should also be non-configurable non-writable or
something. Otherwise you can just redefine it.
You're
Because somebody thought it was a good idea ;-) ...
I'd say for consistency with other constant value properties (NaN,
Infinity, undefined, Math.*, Number.*).
On Jul 21, 2014, at 1:04 PM, Boris Zbarsky wrote:
/ Is this meant to prevent people tampering with them?
//
// In that case,
On Mon, 21 Jul 2014, Allen Wirfs-Brock wrote:
Is there a more up to date version I can look at? I couldn't quite
work out what the canonical file to look at was. I've been using this:
I just release a new PDF draft Friday at
There are two issues here:
1) Is 'default' essential?
2) Should the spec. explicitly define commonjs loading?
Brian is claiming 1) no and 2) no. More important for me: does 2) require
1). Evidently not.
jjb
On Mon, Jul 21, 2014 at 1:34 PM, Brian Di Palma off...@gmail.com wrote:
It
On Jul 21, 2014, at 2:35 PM, Ian Hickson wrote:
On Mon, 21 Jul 2014, Allen Wirfs-Brock wrote:
(Is there a URL that will always point to the very latest version, by any
chance?)
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
is always initialized (by NextJob)
Wasn't the original issue single exports and their demonstrated utility in
node and AMD?
On Jul 21, 2014 5:49 PM, John Barton johnjbar...@google.com wrote:
There are two issues here:
1) Is 'default' essential?
2) Should the spec. explicitly define commonjs loading?
Brian is claiming 1)
What utility is that exactly? They are easier to import in terms of typing?
I would hope that with ES6 modules all a programmer would have to
write is the name of the import and the IDE would auto insert the
import statement.
The sort of IDE support you would see for Java or C#, of course that
On Mon, 21 Jul 2014, Allen Wirfs-Brock wrote:
Yes, this is pretty much what I had in mind.
Cool, thanks.
I mentioned in other message, I can refractor things a bit to make it a
bit easier to express.
Cool, ok. Let me know when I should start speccing things on my end.
However, Realms
On 7/21/14, 5:19 PM, André Bargull wrote:
I'd say for consistency with other constant value properties (NaN,
Infinity, undefined, Math.*, Number.*).
Ah, interesting. I hadn't realized that Math.* and Number.* were also
readonly non-configurable.
Alright, that's as good a reason as any. ;)
35 matches
Mail list logo
