I like this idea mainly because it will allow us to create modules that
explicitly define every used reference. This will help tooling detect
exactly the source of every value we use.
---
A. Matías Quezada
Senior Javascript Developer
amati...@gmail.com
2014-10-05 17:51 GMT+02:00 Brian Di Palma
That was one the intentions but I get the feeling that this change is
either too late or far more complex then it seems.
In future we might have a use strict or use macros for modules
which would enforce this clean slate for modules.
It's not a big deal but I would have preferred the use globals
On 5 October 2014 17:51, Brian Di Palma off...@gmail.com wrote:
1) I think you mean that a parser wants to fail quickly if it comes
across an identifier that was not previously declared as an import but
that could be declared as one deeper in the module file? The simple
solution to that
Hi Andreas,
Thanks for the response and explanations.
I didn't realize how limited in power these fast parsers actually
were, they are basically lexers.
So yes this would require more bookkeeping on their part and that
would impact performance.
I'm doubtful that it would have a significant user
On 8 October 2014 14:11, Brian Di Palma off...@gmail.com wrote:
I didn't realize how limited in power these fast parsers actually
were, they are basically lexers.
No, that's not correct. They have to perform a full syntax check. That
does not imply binding analysis, though, which is usually
Yes, but unfortunately, you cannot distinguish between the two in
JavaScript -- globals, monkey patching, and all that lovely stuff.
And polyfilling - exactly.
___
es-discuss mailing list
es-discuss@mozilla.org
On Wed, Oct 8, 2014 at 1:52 PM, Andreas Rossberg rossb...@google.com wrote:
No, that's not correct. They have to perform a full syntax check. That
does not imply binding analysis, though, which is usually regarded
part of the static semantics of a language, not its (context-free)
syntax.
last time we discussed this, the conclusion was that `Reflect.global` is the
way to go. more details here:
https://gist.github.com/ericf/a7b40bf8324cd1f5dc73#how-do-we-access-the-global-object-within-a-module
once realms landed, it will reflect `realm.global`.
./caridy
On Oct 8, 2014, at 8:52
A compiler can convert references like these
import {myGlobalFunction, MyPolyfilledConstructor} from @global;
myGlobalFunction(42);
into
global.myGlobalFunction(42);
And the global scope can be window for a browser.
This code has the exact same semantics as if the global scope was allowed
On Wed, Oct 8, 2014 at 2:51 PM, caridy car...@gmail.com wrote:
last time we discussed this, the conclusion was that `Reflect.global` is the
way to go. more details here:
https://gist.github.com/ericf/a7b40bf8324cd1f5dc73#how-do-we-access-the-global-object-within-a-module
once realms landed,
var myGlobalFunction = Reflect.global.myGlobalFunction;
note: you can't use import for global due to the nature of the binding process
when importing members or namespaces.
On Oct 8, 2014, at 9:57 AM, Brian Di Palma off...@gmail.com wrote:
On Wed, Oct 8, 2014 at 2:51 PM, caridy
On Wed, Oct 8, 2014 at 3:21 PM, caridy car...@gmail.com wrote:
var myGlobalFunction = Reflect.global.myGlobalFunction;
note: you can't use import for global due to the nature of the binding
process when importing members or namespaces.
I find
import global from @global;
The global could potentially be available via the this module meta syntax:
import { global } from this module;
On 8 October 2014 16:34, Brian Di Palma off...@gmail.com wrote:
On Wed, Oct 8, 2014 at 3:21 PM, caridy car...@gmail.com wrote:
var myGlobalFunction =
Guys, anything that you import is going to be subject to the binding process,
they are immutable values. In the other hand, Reflect.global is just the new
global for scripts and modules, plain and simple.
Today, many libraries are relying on `new Function()` to artificially access
global, and
Does that mean that anything that is imported is frozen?
You can't add properties to any binding you import?
I've never heard of this restriction before.
If that restriction doesn't exist then I'm not sure I see what issue this causes
import { global } from this module;
global in this case is
Brian, my point is that using import to get access to `global` (as you
suggested) is confusing due to the nature of the import, remember the contract:
to import something, someone else has to export it first :)
Aside from that, we don't want to have a exclusive way of accessing globals for
On Wed, Oct 8, 2014 at 4:38 PM, caridy car...@gmail.com wrote:
Brian, my point is that using import to get access to `global` (as you
suggested) is confusing due to the nature of the import, remember the
contract: to import something, someone else has to export it first :)
The JS
what do you mean by:
If the desire was there importing the global would also allow static
errors on free variables.
If we ever decide to allow importing a reference to global from a module, it
has to be a named import, and therefore, no static analysis can be applied to
its members (since
Sorry, I meant free variables inside the module.
The reason why I originally started this thread was to ask if importing
global references or the global would be a way of adding static checks
of free variables in modules.
You are right that you can't check properties of the global.
Hence the
Just use JSHint.
-Original Message-
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brian Di
Palma
Sent: Wednesday, October 8, 2014 12:29
To: caridy
Cc: es-discuss@mozilla.org
Subject: Re: Importing global into modules.
Sorry, I meant free variables inside
-
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brian
Di Palma
Sent: Wednesday, October 8, 2014 12:29
To: caridy
Cc: es-discuss@mozilla.org
Subject: Re: Importing global into modules.
Sorry, I meant free variables inside the module.
The reason why I originally started
I'm probably not understanding all the issues here but I'm also not
explaining my suggestion well either.
The way I see the two issues you raised is like this.
1) I think you mean that a parser wants to fail quickly if it comes
across an identifier that was not previously declared as an import
The recent thread on throwing errors on mutating immutable bindings
touched upon the fact that there is no static unresolvable reference
rejection in modules.
I was wondering if that was down to needing to allow access to
properties set on the global object?
If that's the case why could you not
Brian Di Palma wrote:
The recent thread on throwing errors on mutating immutable bindings
touched upon the fact that there is no static unresolvable reference
rejection in modules.
I was wondering if that was down to needing to allow access to
properties set on the global object?
If that's the
24 matches
Mail list logo
