The latest info from Domenic is:
```js
import { name, url } from this module;
```
Source: http://esdiscuss.org/topic/es6-module-syntax-done
On 28 Aug 2014, at 20:19 , Rick Waldron wrote:
>
>
>
> On Thu, Aug 28, 2014 at 2:17 PM, Matthew Robb wrote:
> From my interpretation of the last face
I'm sorry I must have been thinking about something else. This is what I
pulled from the last notes:
AWB:
> ```js
> import filename from this;
> // which basically: import filename from here;
> ```
> DD: Like this for relative
> DH: Completely amenable to this
> YK:
> ```js
> import * as me from h
On Thu, Aug 28, 2014 at 2:17 PM, Matthew Robb
wrote:
> From my interpretation of the last face to face notes and the breakout
> session it would appear as if instead you will be able to `import mod from
> this`
>
Can you link to the reference?
Rick
>
>
> - Matthew Robb
>
>
> On Thu, Aug 28,
>From my interpretation of the last face to face notes and the breakout
session it would appear as if instead you will be able to `import mod from
this`
- Matthew Robb
On Thu, Aug 28, 2014 at 12:26 PM, John Barton
wrote:
> Was this decision reversed? I don't see Reflect.global in the new spec
Was this decision reversed? I don't see Reflect.global in the new spec.
online.
jjb
On Mon, Jun 9, 2014 at 10:08 AM, Caridy Patino 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 last week. `R
global there (script on a page, not modules)
Do we really want to break interoperability with node.js when it comes to
`this` inside modules which is a keyword that could not even be reassigned
to nothing and/or monkey patched ?
As tweeted earlier today: I can already smell the next stinking
> What is an arrow function bound to in a module?
>
> ```js
> export var a = () => this;
> ```
>
As with all arrow functions, `this` is lexically bound, so it will bind to
whatever `this` is bound to within the module. Which is kinda the question
at hand.
_
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 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 last week. `
>
> 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.
___
e
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
On Mon, Jun 9, 2014 at 9:40 AM, Caridy Patino 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
> will be the di
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:
this.foo = 1;
var bar = 2;
import main from
> 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
> "thi
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 M
> 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 obviou
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
https://m
> Also, @Yehuda Katz 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
https://mail.mozilla.org/listinfo/es-discuss
Also, @Yehuda Katz 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
wrote:
> Because that assum
> 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 wrote:
> Because that assumes everyone needs it all the time. The nice thing about
> it being opt-in is that when it come
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
contribut
> 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
>
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 "./@
(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 wrote:
> I agree with Alex completely. Using `this` as a module meta object is a
> bad idea. Boo.
>
>
> On
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
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 module?
>
> ```
> import mo
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
wrote:
> On Mon Jun 09 2014 at 12:25:42 AM, Domenic Den
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.
> 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 mo
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 9,
On Mon, Jun 9, 2014 at 6:25 AM, Domenic Denicola
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 for an external opt-in fla
Dominic, those are some of the my notes, which by no means cover all the
discussion around this topic. @ericf will be posting the full detailed
explanation of the stuff we covered.
This is definitely an area that we should continue discussing, especially
the API of the "module meta" object, and ho
https://gist.github.com/caridy/eefb9b104874465d4e1c#2-whats-the-execution-context-for-a-module
seems to indicate `this` will become some sort of module meta object with a
variety of abilities: `this.name`, `this.address`, `this.import`, `this.get`,
and `this.module`.
This seems like another unf
32 matches
Mail list logo
