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