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 <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
>>
domenic at domenicdenicola.com (2014-10-15T18:59:01.881Z)
```js
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.
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 <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 >>