IIRC, the compiler doesn't special case handling of that code. "window"
is defined in missing.js so the js.swc knows there is such an entity. Is
there any reason not to add a "global" to node.swc?
-Alex
On 7/13/17, 12:29 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
