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 <offler at gmail.com> wrote:

> >On Wed, Oct 8, 2014 at 3:21 PM, caridy <caridy at 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";
>
> global.myGlobalFunction(42);
>
> more readable.
>
> If we can import module meta information why not import the global object
> too?
> The global should always exist so the binding checks will work, it's a
> module with a default export.
>
> Accessing any global property is via that object.
>
> No need to allow random identifiers floating around modules.
>
> B.
>
> > On Oct 8, 2014, at 9:57 AM, Brian Di Palma <offler at gmail.com> wrote:
> >
> >> On Wed, Oct 8, 2014 at 2:51 PM, caridy <caridy at 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, it will reflect `realm.global`.
> >>
> >> I guess
> >>
> >> import {myGlobalFunction, MyPolyfilledConstructor} from Reflect.global;
> >>
> >> then?
> >>
> >>> ./caridy
> >>>
> >>> On Oct 8, 2014, at 8:52 AM, Andreas Rossberg <rossberg at google.com>
> wrote:
> >>>
> >>>> On 8 October 2014 14:11, Brian Di Palma <offler at 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 regarded
> >>>> part of the static semantics of a language, not its (context-free)
> >>>> syntax. (More by accident than by design, JavaScript so far didn't
> >>>> have much of a static semantics -- at least none that would rule out
> >>>> many programs, i.e., induce compile-time errors. Hence engines could
> >>>> get away with lazy compilation so well.)
> >>>>
> >>>>> I'm doubtful that it would have a significant user perceivable
> effect though.
> >>>>> I imagine modern browser engines perform a lot of work in parallel
> >>>>> where they can.
> >>>>
> >>>> Unfortunately, parallelism doesn't help here, since this is all about
> >>>> the _initial_ parse (of every source), which has to happen before
> >>>> anything else, and so directly affects start-up times.
> >>>>
> >>>>> One way around having an impact on current workloads is to only parse
> >>>>> in this fashion for modules.
> >>>>
> >>>> Yes, see the earlier posts by Dave an myself. Didn't happen, though.
> >>>>
> >>>>> As these modules would be stand alone fast parsing should be
> >>>>> embarrassingly parallel.
> >>>>
> >>>> You can indeed parallelise parsing and checking of separate modules,
> >>>> but each individual task would still take longer, so there would still
> >>>> have been a potential overall cost.
> >>>>
> >>>>> Yes hoisting is another complication, more bookkeeping, it will
> >>>>> probably delay when an error can be raised.
> >>>>> But would you not have to deal with it anyway? Can you not export a
> >>>>> hoisted function?
> >>>>
> >>>> Yes, as I said, recursive scoping (a.k.a. "hoisting") is neither a new
> >>>> nor a significant problem.
> >>>>
> >>>>> Fully closed modules are as you said are probably too tedious - that
> >>>>> can be dropped.
> >>>>> It's more about making modules closed against user defined state as
> >>>>> opposed to system defined state.
> >>>>
> >>>> Yes, but unfortunately, you cannot distinguish between the two in
> >>>> JavaScript -- globals, monkey patching, and all that lovely stuff.
> >>>>
> >>>> /Andreas
> >>>> _______________________________________________
> >>>> es-discuss mailing list
> >>>> es-discuss at mozilla.org
> >>>> https://mail.mozilla.org/listinfo/es-discuss
> >>>
> >
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141008/861fe6c7/attachment.html>

The global could potentially be available via the "this module" meta syntax:

```js
import { global } from this module;
```