On Mon, Jun 9, 2014 at 6:25 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
The current proposal would instead create a
world where `this` is about methods most of the time, but is a magic ambient
variable in some cases (sloppy scripts, modules).
This also creates an ever bigger need
I completely agree and was, in fact, going to write my own email on this topic,
because I strongly believe we should leave `this` alone in modules.
Instead, let’s turn “module this” into a module-local special variable with a
name such as `module`, `thisModule`, `currentModule`, etc.
On Jun
Context:
https://gist.github.com/caridy/eefb9b104874465d4e1c#1-moduleimport-syntax-importdeclaration
```js
module foo from foo; // drop this
import bar from bar;
```
I’m seeing the following contra against dropping ModuleImport syntax:
Contra: without a way to access the module object, it is
I am beginning to come around to the removal. It will just encourage module
authors to use default exports exclusively (e.g. fs will default-export an
object including readFile et al., instead of exporting multiple functions),
which will put us squarely back in parity with the CommonJS/AMD
Isn’t the problem, though, that default-exporting an object prevents static
checking? It feels like an abuse of this feature to me.
With a ModuleImport statement, you have the choice between selectively
importing items and importing everything as an object. With default-exporting
an object,
Many of the Set specific methods would also be useful if they worked on the
keys of Maps.
On Jun 7, 2014 3:44 PM, Hemanth H.M hemanth...@gmail.com wrote:
Yup, a generic collection API.
On Jun 7, 2014 7:10 PM, Calvin Metcalf calvin.metc...@gmail.com wrote:
If you would like to help write a
Why can't we have this?
```js
// when only default exports are used
// import that one function
import mkdirp from mkdirp;
// when only named exports are used
// import it like a module
import fs from fs;
// when both named and default exports are used
// this imports the default export
import
From: Axel Rauschmayer [mailto:a...@rauschma.de]
Isn't the problem, though, that default-exporting an object prevents static
checking? It feels like an abuse of this feature to me.
We don't have static checking today, so this is no loss to me. (And ES6 modules
give enough benefits over ES5
Isn't the problem, though, that default-exporting an object prevents static
checking? It feels like an abuse of this feature to me.
We don't have static checking today, so this is no loss to me.
If I understand ES6 modules correctly, importing a non-exported identifier
gives you a
Axel, using `module` was the first proposal analyzed (3.1 from the gist). I
do like it a lot, but other in the meeting opposed to any sort of automagic
by wrapping the module execution into a function execution with the `module`
argument (a la nodejs),
Overloading `this` feels even more
If the 'module' form is left out, it can be added later. If the 'module'
form is left in, it can never be removed.
jjb
On Mon, Jun 9, 2014 at 6:39 AM, Axel Rauschmayer a...@rauschma.de wrote:
Isn't the problem, though, that default-exporting an object prevents
static checking? It feels like
On the other hand, we’ll have many pseudo-modules, which is also a barrier
against making progress later on.
On Jun 9, 2014, at 15:51 , John Barton johnjbar...@google.com wrote:
If the 'module' form is left out, it can be added later. If the 'module' form
is left in, it can never be
On Mon, Jun 9, 2014 at 6:54 AM, Axel Rauschmayer a...@rauschma.de wrote:
On the other hand, we’ll have many pseudo-modules, which is also a barrier
against making progress later on.
Sorry, I don't understand what a pseudo-module is. Are you saying that the
core import/export system is not
On Mon Jun 09 2014 at 12:25:42 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
If a magically in-scope binding is necessary to access module meta
capabilities, giving it a name like `module` or `System.currentModule`
would be much better.
`System.currentModule` requires magic. It
I’m assuming that people will default-export objects (for Underscore.js-like
libraries). I’d call those pseudo-modules, because one would be partially
working around the module system (no load-time errors!).
Maybe we’ll import modules like this [^1], but that feels syntactically
inconsistent
What if instead of any sort of magic there was a special relative import a
person could specify to get access to the this module?
```
import module from @currentModule;
```
- Matthew Robb
On Mon, Jun 9, 2014 at 7:46 AM, Erik Arvidsson erik.arvids...@gmail.com
wrote:
On Mon Jun 09 2014 at
I would like to see a reigning in of uses of curly braces. We already have
at least these:
1) code blocks
2) literal objects
3) destructuring
I don't like that the module syntax adds yet another. I'd like to think of
the curly braces in the module syntax as being like destructuring. That way
the
I agree with Alex completely. Using `this` as a module meta object is a
bad idea. Boo.
On Mon, Jun 9, 2014 at 11:03 AM, Matthew Robb matthewwr...@gmail.com
wrote:
What if instead of any sort of magic there was a special relative import a
person could specify to get access to the this
I agree with Alex.
We can tolerate this syntactic form being dropped for now, but that doesn't
eliminate the semantic need. If the module contextual keyword is a
problem, then we should be able to come up with another color for the
bikeshed, e.g.:
import foo as foo;
As an aside, it is yet
(Sorry for the boo, but I can't mask my disappointment here.)
Erik, was was Dave's argument that a new binding is a non-starter?
Thanks!
On Mon, Jun 9, 2014 at 11:11 AM, Kevin Smith zenpars...@gmail.com wrote:
I agree with Alex completely. Using `this` as a module meta object is a
bad
I guess it just seems odd to me that we HAVE a system in place now for
importing stuff into a Program with an author defined local identifier
name and we're discussing magic like using this or module. Just make it
another thing the author imports inside their own module? ``` import meta
from
I guess it just seems odd to me that we HAVE a system in place now for
importing stuff into a Program with an author defined local identifier
name and we're discussing magic like using this or module. Just make it
another thing the author imports inside their own module? ``` import meta
from
On a meta level, I'm continually frustrated by the fact that participants
in the module design refuse to share their ideas on es-discuss until a TC39
meeting review is posted (which usually coincides with some kind of
resolution). Community input is a good thing, right?
On Sat, Jun 7, 2014 at
As an aside, it is yet to be seen whether the default export thing is the
best way, or the bad part itself. We don't have the real world experience
yet to answer that.
I’d even argue that they led to the predicament that we are currently in.
If the default export didn’t look like “the
Because that assumes everyone needs it all the time. The nice thing about
it being opt-in is that when it comes time to use it a person has to first
learn the entry point and from then on be explicit about it. I prefer
explicitness 99% of the time because it's easier to track down for new
Also, if module were a reserved word and not already used by node.js as an
identifier I MIGHT feel differently.
- Matthew Robb
On Mon, Jun 9, 2014 at 8:28 AM, Matthew Robb matthewwr...@gmail.com wrote:
Because that assumes everyone needs it all the time. The nice thing about
it being opt-in
Because that assumes everyone needs it all the time. The nice thing about
it being opt-in is that when it comes time to use it a person has to first
learn the entry point and from then on be explicit about it. I prefer
explicitness 99% of the time because it's easier to track down for new
Also, @Yehuda Katz wyc...@gmail.com argued that `module` is a common
variable name (QUnit uses it) and reserving it is a non starter.
`import {thisModule as yourName} from '@moduleMeta'` (bike shedding TBD) is
a promising path forward.
On Mon Jun 09 2014 at 11:28:59 AM, Matthew Robb
Most of these could just be methods of iterators and then they could be
used for different data structures seemlessly.
On Mon Jun 09 2014 at 3:19:20 AM, Calvin Metcalf calvin.metc...@gmail.com
wrote:
Many of the Set specific methods would also be useful if they worked on
the keys of Maps.
On
Also, @Yehuda Katz wyc...@gmail.com argued that `module` is a common
variable name (QUnit uses it) and reserving it is a non starter.
That makes sense - thanks!
___
es-discuss mailing list
es-discuss@mozilla.org
Agreed. Side discussions are sometimes needed but please make sure we keep
track of what was discussed. For the last TC39 I asked everyone that did a
breakout session to take notes and share these. Caridy did a really good
job sharing these notes.
On Mon Jun 09 2014 at 11:27:12 AM, Kevin Smith
My perspective here is that there are not too many modules (in nodejs) that
rely on more than a handful of exports from a particular module, we are
actively working on validating this using esprima in a large set of npm
modules. If this is true, we should be just fine with specific imports, and
Traceur definitely has a lot of exports in a single module.
https://github.com/google/traceur-compiler/blob/master/src/syntax/Parser.js#L15
We do not however, use the `module` form since we want to get rid of the
extra Get (which deopts switch statements in some engines).
On Mon Jun 09 2014 at
esparse used to have a module which exported a huge list of things, and
for the same reason I believe.
Basically there's an AST module which exports a huge list of AST
node-type classes. That module is then exported to the public interface.
Actually, that is something that I do understand. esdiscussions *can* be
unproductive and emotional. Thus: it’s a tricky balance – getting work done vs.
keeping everybody informed and getting feedback. I don’t believe in design by
democracy.
David Herman has mentioned on Twitter that he’ll
Actually, that is something that I do understand. esdiscussions *can* be
unproductive and emotional. Thus: it’s a tricky balance – getting work done
vs. keeping everybody informed and getting feedback. I don’t believe in
design by democracy.
Nor do I. It seems to me that the design process
On Mon, Jun 9, 2014 at 7:51 AM, Axel Rauschmayer a...@rauschma.de wrote:
I’m assuming that people will default-export objects (for
Underscore.js-like libraries). I’d call those pseudo-modules, because one
would be partially working around the module system (no load-time errors!).
Then aren't
Just another related issue: in Traceur code we use 'this' in modules to
mean 'global', because in modules we have no other way to say 'global' in
code designed to work in browsers and node.
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
On Mon, Jun 9, 2014 at 9:08 AM, John Barton johnjbar...@google.com wrote:
[...]
but ES6 is a class-based language: based on our experience the majority
of exports going forward will be classes.
Hi John, that sounds interesting. What more can you tell us about that
experience?
--
Just another related issue: in Traceur code we use 'this' in modules to
mean 'global', because in modules we have no other way to say 'global' in
code designed to work in browsers and node.
Right - I do the same. I think leaving this to mean global would be just
fine: there's no obvious
Pirouette also has many exports per module for its bindings:
E.g.
https://github.com/toshok/pirouette/blob/master/bindings/uikit.js.
I use both import-{}-from (with many imported bindings) and module-from forms,
tending toward the former in framework code and the latter in application code.
The genuine global is typically the source of tremendous amounts of
authority. Much of the mechanism of SES is built to deny access to the
genuine global and to non-whitelisted global variables. Can the module
loader API be used to load a module with a different top level binding for
this?
On
but ES6 is a class-based language: based on our experience the majority
of exports going forward will be classes.
Hi John, that sounds interesting. What more can you tell us about that
experience?
My experience also agrees with John's. It just makes sense from a
design-perspective to
Chris, the number of exports is not relevant, and in fact, there is no way
to export all members in one go, which aligns well with the proposal to
remove the way to import an object with all members. check the consumers of
the `uikit` module, and count how many of those exported methods are used
The genuine global is typically the source of tremendous amounts of
authority. Much of the mechanism of SES is built to deny access to the
genuine global and to non-whitelisted global variables. Can the module
loader API be used to load a module with a different top level binding for
this?
Chris, the number of exports is not relevant, and in fact, there is no way
to export all members in one go, which aligns well with the proposal to
remove the way to import an object with all members. check the consumers of
the `uikit` module, and count how many of those exported methods are
IIUC, the motivation for dropping the form is that it's confusing to have
this other syntactic option which uses a different (contextual) keyword.
Well, we already have this:
import ./foo;
which you can use when you want to load+execute but not import anything.
Is that going away? If not,
another issue with `this` being `global` (as it is today by the specs) is
the way top level modules will be defined in a page, assuming we will have
`type=module` for scripts (which is probably were we want to be), what
will be the difference between:
script type=module
this.foo = 1;
var bar = 2;
`import ./foo as foo;` certainly looks nice.
On Mon, Jun 9, 2014 at 12:36 PM, Kevin Smith zenpars...@gmail.com wrote:
IIUC, the motivation for dropping the form is that it's confusing to have
this other syntactic option which uses a different (contextual) keyword.
Well, we already have
On Mon, Jun 9, 2014 at 9:17 AM, Mark S. Miller erig...@google.com wrote:
On Mon, Jun 9, 2014 at 9:08 AM, John Barton johnjbar...@google.com
wrote:
[...]
but ES6 is a class-based language: based on our experience the majority
of exports going forward will be classes.
Hi John, that sounds
That particular use of module-from is a little special. @objc_internal is a
native module. Once ejs supports enumerating multiple exports from native
modules I'll be switching that to an import-{}-from.
An example of use would be my toy test applications that consume the modules:
And the as portion can be optional if all you want is import dude effects.
On Jun 9, 2014 9:42 AM, Caridy Patino car...@gmail.com wrote:
`import ./foo as foo;` certainly looks nice.
On Mon, Jun 9, 2014 at 12:36 PM, Kevin Smith zenpars...@gmail.com wrote:
IIUC, the motivation for dropping
Gah.. Phone. Side-effects*
On Jun 9, 2014 9:47 AM, matthewwr...@gmail.com wrote:
And the as portion can be optional if all you want is import dude effects.
On Jun 9, 2014 9:42 AM, Caridy Patino car...@gmail.com wrote:
`import ./foo as foo;` certainly looks nice.
On Mon, Jun 9, 2014 at 12:36
On Mon, Jun 9, 2014 at 9:40 AM, Caridy Patino car...@gmail.com wrote:
another issue with `this` being `global` (as it is today by the specs) is
the way top level modules will be defined in a page, assuming we will have
`type=module` for scripts (which is probably were we want to be), what
On Mon, Jun 9, 2014 at 8:33 AM, Erik Arvidsson erik.arvids...@gmail.com wrote:
Most of these could just be methods of iterators and then they could be used
for different data structures seemlessly.
In other words, just look at what Python did, and only change things
when you're sure there was a
FWIW, I like the nodejs approach where `this` is the module itself which as
virtual sandbox is the only `this` I'd expect. To reach the global maybe
we should think about adding a `global` indeed while having `this`
undefined would be just making modules not so reusable or portable and
would make
My point: if 'this' is not global in modules, then ES6 must have an
alternative way to name the global object.
Yes, we covered that last week. `Reflect.global` seems like the right place
for it considering that it will be defined per realm.
___
On Sat, Jun 7, 2014 at 3:41 PM, Brendan Eich bren...@mozilla.org wrote:
Tab Atkins Jr. wrote:
On Fri, Jun 6, 2014 at 1:57 PM, Andy Wingowi...@igalia.com wrote:
1: Essential differences
==
Array comprehensions are eager. Generator comprehensions are lazy.
Array comprehensions
Why can't we have both with the same syntax?
```js
// imports a function which is the default export
import mkdirp from mkdirp;
```
and
```js
// imports all named exports, like module used to
import fs from fs;
```
On Mon, Jun 9, 2014 at 5:50 PM, Matthew Robb matthewwr...@gmail.com wrote:
On Mon, Jun 9, 2014 at 7:40 PM, Karolis Narkevičius karoli...@gmail.com
wrote:
Why can't we have both with the same syntax?
```js
// imports a function which is the default export
import mkdirp from mkdirp;
```
and
```js
// imports all named exports, like module used to
import fs from
What is an arrow function bound to in a module?
```js
export var a = () = this;
```
On Mon, Jun 9, 2014 at 7:08 PM, Caridy Patino car...@gmail.com wrote:
My point: if 'this' is not global in modules, then ES6 must have an
alternative way to name the global object.
Yes, we covered that
```
ImportClause :
ImportedBinding
ImportedBinding , NamedImports
NamedImports
```
Side topic, but this particular production:
ImportClause: ImportedBinding , NamedImports
needs to die an immediate death.
Or would the default value be an object containing all the named
once again, in node.js `this` is the exported module. I think we should not
make it `undefined` neither a `global` pointer ... in node.js `this` in
modules is never global except when you launch the console so only in the
main, where we are already consistently good on browsers since `this` is
the
I like the idea of value types, but I wonder if, for terminating decimal
numbers, the .valueOf() method from Object.prototype might be sufficient
for many operations.
Example:
function SmallDecimal(k) {
this.__value__ = k;
}
SmallDecimal.prototype.valueOf = function() {
return
64 matches
Mail list logo
