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 modules, they should be accessible (as reflective) from everywhere. /caridy On Oct 8, 2014, at 11:17 AM, Brian Di Palma <[email protected]> wrote: > 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 an object and I was under the impression that you > could add and remove properties to an object if you imported one. > > Providing an idiomatic way for modules to access the global seems good > ergonomics. > > > On Wed, Oct 8, 2014 at 4:00 PM, caridy <[email protected]> wrote: >> 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 that's wont work with CSP, therefore we need to provide a >> reliable way to access global from anywhere, not only from modules. >> >> /caridy >> >> On Oct 8, 2014, at 10:34 AM, Brian Di Palma <[email protected]> wrote: >> >>>> On Wed, Oct 8, 2014 at 3:21 PM, caridy <[email protected]> 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 <[email protected]> wrote: >>>> >>>>> On Wed, Oct 8, 2014 at 2:51 PM, caridy <[email protected]> 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 <[email protected]> wrote: >>>>>> >>>>>>> On 8 October 2014 14:11, Brian Di Palma <[email protected]> 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 >>>>>>> [email protected] >>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>> >>>> >> _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
