Right now, if you have code that looks like this, the compiler will report and
error and it will fail:
global[“foo”];
I would like for that to be legal code in a COMPILE::JS block and it should
compile to:
global[“foo”];
Exactly the same as window:
If you write:
window[“foo”];
It’s legal code and will compile to:
window[“foo”];
That’s it.
> On Jul 13, 2017, at 10:18 AM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>
> I'm still not clear what changes are needed.
>
> Are you trying to access APIs that are global but not defined in JS.SWC or
> Node.SWC? Otherwise, the APIs on window/global should be defined in those
> SWCs.
>
> I'm not sure what the test case is supposed to look like.
>
> Thanks,
> -Alex
>
> On 7/13/17, 12:11 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>
>> Electron has both window and global. Node has global and no window. I
>> think CEF has window and no global. Browsers have window but not global.
>> Depending on which environment you are writing for, you’re going to need
>> either window or global for accessing global variables.
>>
>> I’m more concerned with general global access in Node than my specific
>> use case. If general global access works, then that gives a solution for
>> my specific case as well as an other arbitrary one where you’d use window
>> in the browser.
>>
>> I think it’s fine to cross compile global[“foo”] to the exact same
>> global[“foo”] in JS. In other words, the compiler should accept global
>> with bracket notation and pass it through unchanged.
>>
>>> On Jul 13, 2017, at 9:33 AM, Alex Harui <aha...@adobe.com.INVALID>
>>> wrote:
>>>
>>> I think the only thing the compiler does with "window" is allow you to
>>> use
>>> "window" to disambiguate between a "global" API and another API in a
>>> package with the same name.
>>>
>>> And then the JS.SWC typedefs specify certain APIs.
>>>
>>> AIUI, Electron is another runtime that has a window variable and you
>>> want
>>> to detect the difference between Browser, Node and Electron? Or are you
>>> willing to just try to check for features instead?
>>>
>>> If you can show what JS code you'd want to end up with we can look into
>>> changing the compiler so you can write AS to generate that JS.
>>>
>>> Thanks,
>>> -Alex
>>>
>>> On 7/12/17, 9:03 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>>>
>>>> What do we currently do with window?
>>>>
>>>> global in Node is the same as window in the browser. All global
>>>> variables
>>>> are attached to the global object.
>>>>
>>>> global[“foo”] could compile to global[“foo”], global.foo, or just plain
>>>> foo, and it all means the same thing.
>>>>
>>>>> On Jul 13, 2017, at 2:14 AM, Alex Harui <aha...@adobe.com.INVALID>
>>>>> wrote:
>>>>>
>>>>> What AS do you want to write and what JS do you want as output?
>>>>>
>>>>> -Alex
>>>>>
>>>>> On 7/9/17, 12:53 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>>>>>
>>>>>> Checking for window will work for Node, but it will not work for
>>>>>> Electron.
>>>>>>
>>>>>> I tried adding global to Falcon, but I was obviously going about it
>>>>>> wrong, because what I tried did not work.
>>>>>>
>>>>>> This is not really high priority for me right now, so I’m moving on
>>>>>> to
>>>>>> something else…
>>>>>>
>>>>>>> On Jul 6, 2017, at 3:05 AM, Alex Harui <aha...@adobe.com.INVALID>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I've noticed lots of advice on the internet to use feature detection
>>>>>>> instead of browser/runtime detection. Did you rule out doing that?
>>>>>>> Browsers may implement new features over time.
>>>>>>>
>>>>>>> But otherwise, I see some clever tests that check for "window" and a
>>>>>>> few
>>>>>>> other things.
>>>>>>>
>>>>>>> HTH,
>>>>>>> -Alex
>>>>>>>
>>>>>>> On 7/5/17, 1:54 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>>>>>>>
>>>>>>>> No. I was trying to use process to check whether it’s running in a
>>>>>>>> Node
>>>>>>>> runtime (such as Node or Electron). window does not have process.
>>>>>>>>
>>>>>>>> I’m trying to add a class that lets the client know what
>>>>>>>> environment
>>>>>>>> it’s
>>>>>>>> running in.
>>>>>>>>
>>>>>>>> Adding global sounds like a good idea. Between window and global, I
>>>>>>>> think
>>>>>>>> that would offer a solution everywhere.
>>>>>>>>
>>>>>>>>> On Jul 5, 2017, at 7:48 PM, Alex Harui <aha...@adobe.com.INVALID>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Sure, I know it wouldn't work at runtime, but it sounded like
>>>>>>>>> Harbs
>>>>>>>>> couldn't even get the compiler to accept window["process"] which
>>>>>>>>> it
>>>>>>>>> should.
>>>>>>>>>
>>>>>>>>> So, it should be ok to write:
>>>>>>>>>
>>>>>>>>> if(typeof window !== "undefined")
>>>>>>>>> {
>>>>>>>>> theProcess = window["process"];
>>>>>>>>> }
>>>>>>>>> else
>>>>>>>>>
>>>>>>>>> theProcess = global.process
>>>>>>>>>
>>>>>>>>> But is there really a process property in the browser?
>>>>>>>>>
>>>>>>>>> We could create or own single variable if we want. How often do
>>>>>>>>> libraries
>>>>>>>>> need stuff in window/global? Classes that need it should be able
>>>>>>>>> to
>>>>>>>>> use
>>>>>>>>> inject_html and run some JS that maps window to global or the
>>>>>>>>> other
>>>>>>>>> way
>>>>>>>>> around.
>>>>>>>>>
>>>>>>>>> HTH,
>>>>>>>>> -Alex
>>>>>>>>>
>>>>>>>>> On 7/5/17, 6:43 AM, "Josh Tynjala" <joshtynj...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Node.js doesn't have a window variable, so window["process"]
>>>>>>>>>> won't
>>>>>>>>>> work.
>>>>>>>>>> They have a global variable instead.
>>>>>>>>>>
>>>>>>>>>> I remember reading that there is a proposal for ECMAScript to
>>>>>>>>>> standardize
>>>>>>>>>> a
>>>>>>>>>> single variable that refers to window in the browser and global
>>>>>>>>>> in
>>>>>>>>>> Node.js,
>>>>>>>>>> but that doesn't exist yet.
>>>>>>>>>>
>>>>>>>>>> - Josh
>>>>>>>>>>
>>>>>>>>>> On Tue, Jul 4, 2017 at 11:35 PM, Alex Harui
>>>>>>>>>> <aha...@adobe.com.invalid>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> What class in Core needs this dependency? I think one drawback
>>>>>>>>>>> is
>>>>>>>>>>> that
>>>>>>>>>>> users of that class will need to add node.swc to their project
>>>>>>>>>>> dependencies. But I don't think every consumer of Core will
>>>>>>>>>>> need
>>>>>>>>>>> node.swc.
>>>>>>>>>>>
>>>>>>>>>>> But first, why didn't window["process"] work? In theory Falcon
>>>>>>>>>>> will
>>>>>>>>>>> let
>>>>>>>>>>> you access anything off of window. We could also add global if
>>>>>>>>>>> we
>>>>>>>>>>> want.
>>>>>>>>>>> Or maybe we should only allow global and have some bootstrap
>>>>>>>>>>> code
>>>>>>>>>>> that
>>>>>>>>>>> maps global to window?
>>>>>>>>>>>
>>>>>>>>>>> -Alex
>>>>>>>>>>>
>>>>>>>>>>> On 7/4/17, 2:09 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Actually, I see that the Node typedefs has all the process
>>>>>>>>>>>> declarations
>>>>>>>>>>>> in global.js.
>>>>>>>>>>>>
>>>>>>>>>>>> Is there an issue with adding a dependency in CoreJS to
>>>>>>>>>>>> node.swc?
>>>>>>>>>>>>
>>>>>>>>>>>> Should a class that has this dependency go somewhere else? (I
>>>>>>>>>>>> don’t
>>>>>>>>>>>> really see an issue with adding the dependency, but I’m
>>>>>>>>>>>> throwing
>>>>>>>>>>>> this
>>>>>>>>>>> out
>>>>>>>>>>>> in case I’m missing something.)
>>>>>>>>>>>>
>>>>>>>>>>>> Harbs
>>>>>>>>>>>>
>>>>>>>>>>>>> On Jul 5, 2017, at 12:00 AM, Harbs <harbs.li...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Looks like it.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I see this in missing.js:
>>>>>>>>>>>>>
>>>>>>>>>>>>> /**
>>>>>>>>>>>>> * @export
>>>>>>>>>>>>> * This gets mapped to org.apache.flex.utils.Language.trace()
>>>>>>>>>>>>> by
>>>>>>>>>>>>> the
>>>>>>>>>>>>> compiler
>>>>>>>>>>>>> * @param {...} rest
>>>>>>>>>>>>> */
>>>>>>>>>>>>> function trace(rest) {}
>>>>>>>>>>>>>
>>>>>>>>>>>>> /**
>>>>>>>>>>>>> * @type {!Console}
>>>>>>>>>>>>> * @const
>>>>>>>>>>>>> */
>>>>>>>>>>>>> var console;
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I guess I can add another one like so:
>>>>>>>>>>>>>
>>>>>>>>>>>>> /**
>>>>>>>>>>>>> * @type {!Process}
>>>>>>>>>>>>> * @const
>>>>>>>>>>>>> */
>>>>>>>>>>>>> var process;
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, it seems like a drag to have to add a typedef every
>>>>>>>>>>>>> time
>>>>>>>>>>>>> a
>>>>>>>>>>>>> developer needs to check for the existence of a global that we
>>>>>>>>>>>>> did
>>>>>>>>>>>>> not
>>>>>>>>>>>>> think of.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jul 4, 2017, at 9:13 PM, Harbs <harbs.li...@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks. Here’s what I see:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> if(typeof window !== "undefined")
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> theConsole = window.console;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>> else if(typeof console !== "undefined")
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> theConsole = console;
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Did you define console in a typedef maybe?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I’m thinking that Falcon should really allow undefined
>>>>>>>>>>>>>> variables
>>>>>>>>>>> when
>>>>>>>>>>>>>> used with “typeof”.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Truth be told, I really need to do something like one of
>>>>>>>>>>>>>> these:
>>>>>>>>>>>>>> if(typeof (process) != 'undefined' &&
>>>>>>>>>>>>>> {}.toString.call(process)
>>>>>>>>>>>>>> ==
>>>>>>>>>>>>>> '[object process]’)
>>>>>>>>>>>>>> or:
>>>>>>>>>>>>>> if(typeof process != 'undefined' && process &&
>>>>>>>>>>>>>> process.constructor.name == "process”)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Of course every reference to process causes a compiler
>>>>>>>>>>>>>> error. I
>>>>>>>>>>> wonder
>>>>>>>>>>>>>> if there’s some way to tell the compiler to accept it without
>>>>>>>>>>>>>> complaining…
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Jul 4, 2017, at 8:54 PM, Josh Tynjala
>>>>>>>>>>>>>>> <joshtynj...@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I don't remember exactly what I did, but in order to get
>>>>>>>>>>>>>>> trace()
>>>>>>>>>>>>>>> working in
>>>>>>>>>>>>>>> Node.js, I had to figure out how to find the console object
>>>>>>>>>>>>>>> on
>>>>>>>>>>> window
>>>>>>>>>>>>>>> versus global. I feel like I remember using typeof, but
>>>>>>>>>>>>>>> maybe
>>>>>>>>>>>>>>> it
>>>>>>>>>>> was
>>>>>>>>>>>>>>> something else. Take a look at the implementation of
>>>>>>>>>>> Language.trace()
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> see what I did.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Josh
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Jul 4, 2017 5:26 AM, "Harbs" <harbs.li...@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I’m trying to figure out how to solve this dilemma:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Browsers attach global variables to window.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Node.js attaches globals to global.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I’m trying to check for the existence of a global called
>>>>>>>>>>>>>>>> process.
>>>>>>>>>>> In
>>>>>>>>>>>>>>>> JS,
>>>>>>>>>>>>>>>> you’d generally do that by checking typeof process ==
>>>>>>>>>>>>>>>> ‘undefined’.
>>>>>>>>>>>>>>>> Falcon
>>>>>>>>>>>>>>>> does not allow you to do that and complains that process is
>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>> undefined
>>>>>>>>>>>>>>>> property. In the browser you can use window[“process”] ==
>>>>>>>>>>> undefined
>>>>>>>>>>>>>>>> and in
>>>>>>>>>>>>>>>> node you can (theoretically) use global[“process”] ==
>>>>>>>>>>>>>>>> undefined.
>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>> can’t
>>>>>>>>>>>>>>>> think of a generic way to do this though.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thoughts?
>>>>>>>>>>>>>>>> Harbs
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
