On Wed, Jun 25, 2014 at 4:50 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
@John Barton: Yes, ideally that syntax would work as well when you don't
need a namespace. But sometimes you do need a namespace, even if you don't
care precisely what it is:
```
import {format} from 'url';
Nice.
I wonder what Horse would think of Vermin Supreme's pony identification program.
But in all seriousness, Google, MSFT, are all pushing for IoT or
wearables by putting on events featuring that, creating a buzz, and
making press on the event.
On 6/23/14, Brendan Eich bren...@mozilla.org
Has the ECMAScript specification license problem been resolved? If so, how?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Thu, Jun 26, 2014 at 8:15 AM, Kevin Smith zenpars...@gmail.com wrote:
I agree, and importing as a namespace is what ModuleImport is all about.
Crazy idea: what if we had this:
// ModuleImport: import Identifier from StringLiteral
import fs from fs;
import url from url;
(I’m happy with David’s proposal, but I’d like to try bikeshedding one more
time.)
Building on an idea by Kevin Smith: how about supporting default exports
without any explicit syntactic constructs? The convention would be: the name
`_` is used for default exports. The following is a
Now the author can choose to export more things later without making
breaking changes to the module. The only downside to this is the
(apparently mandatory) curly braces around the imported object. If single
export/import becomes the convention with ES6 modules then users will be
forced to
(I’m happy with David’s proposal, but I’d like to try bikeshedding one
more time.)
For my part, I no longer think that the import * as foo change solves
anything. The underlying problem is default exports - it's just plain
confusing to users.
// main.js
import { _ as MyClass } from
On Thu, Jun 26, 2014 at 3:39 PM, Kevin Smith zenpars...@gmail.com wrote:
The underlying problem is default exports - it's just plain confusing to
users.
I agree
What do you think? Is there any user experience issue here that needs to
be sugared over?
Notice that, on the import side,
the slight difference in `import { MyClass } from my-class.js;` compared
to `var MyClass = require(./my-class.js);` is that in cjs MyClass is a
variable the user create, meaning the user only need to know about 1 name
from the remote module, the path, but in ES6 MyClass is set by the exporter
On Jun 25, 2014, at 11:48 PM, musicdenotat...@gmail.com wrote:
Has the ECMAScript specification license problem been resolved? If so, how?
see http://www.ecma-international.org/memento/Ecma%20copyright%20FAQ.htm
___
es-discuss mailing list
On Thu, Jun 26, 2014 at 9:56 AM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
the slight difference in `import { MyClass } from my-class.js;`
compared to `var MyClass = require(./my-class.js);` is that in cjs
MyClass is a variable the user create, meaning the user only need to know
about 1
First - I reject the idea that making the export anonymous is in any way
good practice. Frankly, naming things is essential to API design.
Here's a concrete example of why you should always name your exports:
// A.js
export class A {}
// B.js
export class B {}
//
If you rely on anonymous exports, you're going to be SOL when trying to
aggregate like this.
Sorry, meant to add that I aggregate like this *all* the time.
___
es-discuss mailing list
es-discuss@mozilla.org
// my-class.js
export class MyClass {
constructor() { ... }
method() { ... }
}
// use-class.js
import { MyClass } from my-class.js;
You do have redundancy in `my-class.js` and, as Marius pointed out, the
importer has to know both the name of the
On Thu, Jun 26, 2014 at 7:39 AM, Axel Rauschmayer a...@rauschma.de wrote:
// my-class.js
export class MyClass {
constructor() { ... }
method() { ... }
}
// use-class.js
import { MyClass } from my-class.js;
You do have redundancy in `my-class.js` and,
Now the author can choose to export more things later without making
breaking changes to the module. The only downside to this is the
(apparently mandatory) curly braces around the imported object. If single
export/import becomes the convention with ES6 modules then users will be
forced to
On Thu, Jun 26, 2014 at 10:50 AM, Russell Leggett russell.legg...@gmail.com
wrote:
To me, though, that goes back to the destructuring/not destructuring
aspect. Maybe this has floated by during the bikeshedding, but why not
something like:
//import a single named export
import foo
On Thu, Jun 26, 2014 at 9:39 AM, Kevin Smith zenpars...@gmail.com wrote:
(I’m happy with David’s proposal, but I’d like to try bikeshedding one
more time.)
For my part, I no longer think that the import * as foo change solves
anything. The underlying problem is default exports - it's just
On Thu, Jun 26, 2014 at 9:50 AM, Russell Leggett russell.legg...@gmail.com
wrote:
To me, though, that goes back to the destructuring/not destructuring
aspect. Maybe this has floated by during the bikeshedding, but why not
something like:
//import a single named export
import foo
I like the fact that this doesn't look like destructuring, since variable
binding is different from destructuring assignment. Could
```
import foo, baz from bar as bar;
```
allowed simultanous import of named exports and the module itself? If so,
the grammar gains a pleasing regularity.
let C be some constructor
let D = C.bind(obj, a, b)
Thanks to the carefully designed `D.[[Construct]]` internal method, the
following expressions are equivalent:
new D(...args)
new C(a, b, ...args)
Consider now:
class E extends D {
contructor(...args) {
Hmm
On Jun 26, 2014, at 9:57 AM, Claude Pache wrote:
let C be some constructor
let D = C.bind(obj, a, b)
Thanks to the carefully designed `D.[[Construct]]` internal method, the
following expressions are equivalent:
Hmmand showing that perhaps is isn't so easy to get rid
On Thu, Jun 26, 2014 at 2:41 AM, Garrett Smith dhtmlkitc...@gmail.com
wrote:
Nice.
I wonder what Horse would think of Vermin Supreme's pony identification
program.
But in all seriousness, Google, MSFT, are all pushing for IoT or
wearables by putting on events featuring that, creating a
To me, though, that goes back to the destructuring/not destructuring
aspect. Maybe this has floated by during the bikeshedding, but why not
something like:
//import a single named export
import foo from bar;
//import multiple named exports
import foo, baz from bar;
24 matches
Mail list logo
