You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Harbs <ha...@gmail.com> on 2017/07/04 12:26:22 UTC

[FlexJS] Use of typeof

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

Re: [FlexJS] Use of typeof

Posted by Josh Tynjala <jo...@gmail.com>.
I just gave it a try, and I'm not seeing global either. It appears that
"var global" is not defined in the typedefs. I guess we'll need to add it
to the missing.js for Node.

- Josh

On Thu, Jul 13, 2017 at 10:09 AM, Harbs <ha...@gmail.com> wrote:

> Adding node.swc makes things like require be recognized, but global is
> still not. Odd. I thought I saw it in the typedefs.
>
> > On Jul 13, 2017, at 8:04 PM, Harbs <ha...@gmail.com> wrote:
> >
> > Are you saying we should add node.swc to Core?
> >
> > FWIW, I just tried setting targets to JSNode and global is still not
> recognized. node.swc does not seem to be used even when that’s the target.
> That does not seem right either.
> >
> >> On Jul 13, 2017, at 7:42 PM, Josh Tynjala <jo...@gmail.com>
> wrote:
> >>
> >> I think the correct solution is to add node.swc to the
> >> -external-library-path when you need access to global. You need js.swc
> on
> >> the -external-library-path when you want to access window. You can't use
> >> window in a SWF-only project, for instance.
> >>
> >> - Josh
> >>
> >> On Thu, Jul 13, 2017 at 9:29 AM, Harbs <ha...@gmail.com> wrote:
> >>
> >>> There is a mention of window in the NativeJSType enums. Not sure why
> it’s
> >>> needed there.
> >>>
> >>> global should already be in node.js (I think). I’m pretty sure it’s
> >>> defined in the node typedefs
> >>>
> >>> I don’t really care how it’s achieved, but by default (without doing
> any
> >>> special imports) global should be recognized. (just like window is)
> >>>
> >>> Right now, typing global into a FlexJS project targeting “JSFlex” or
> any
> >>> one of the framework projects results in a compiler error. How do we
> fix
> >>> that?
> >>>
> >>>> On Jul 13, 2017, at 7:17 PM, Alex Harui <ah...@adobe.com.INVALID>
> >>> wrote:
> >>>>
> >>>> 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" <ha...@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 <ah...@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" <ha...@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 <aharui@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" <ha...@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
> <ah...@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" <ha...@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
> <aharui@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" <ha...@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
> >>>>>>>>>>>>>> <ah...@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" <jo...@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
> >>>>>>>>>>>>>>> <ah...@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" <ha...@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.lists@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.lists@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
> >>>>>>>>>>>>>>>>>>>> <jo...@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.lists@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
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >
>
>

Re: [FlexJS] Use of typeof

Posted by Harbs <ha...@gmail.com>.
Adding node.swc makes things like require be recognized, but global is still not. Odd. I thought I saw it in the typedefs.

> On Jul 13, 2017, at 8:04 PM, Harbs <ha...@gmail.com> wrote:
> 
> Are you saying we should add node.swc to Core?
> 
> FWIW, I just tried setting targets to JSNode and global is still not recognized. node.swc does not seem to be used even when that’s the target. That does not seem right either.
> 
>> On Jul 13, 2017, at 7:42 PM, Josh Tynjala <jo...@gmail.com> wrote:
>> 
>> I think the correct solution is to add node.swc to the
>> -external-library-path when you need access to global. You need js.swc on
>> the -external-library-path when you want to access window. You can't use
>> window in a SWF-only project, for instance.
>> 
>> - Josh
>> 
>> On Thu, Jul 13, 2017 at 9:29 AM, Harbs <ha...@gmail.com> wrote:
>> 
>>> There is a mention of window in the NativeJSType enums. Not sure why it’s
>>> needed there.
>>> 
>>> global should already be in node.js (I think). I’m pretty sure it’s
>>> defined in the node typedefs
>>> 
>>> I don’t really care how it’s achieved, but by default (without doing any
>>> special imports) global should be recognized. (just like window is)
>>> 
>>> Right now, typing global into a FlexJS project targeting “JSFlex” or any
>>> one of the framework projects results in a compiler error. How do we fix
>>> that?
>>> 
>>>> On Jul 13, 2017, at 7:17 PM, Alex Harui <ah...@adobe.com.INVALID>
>>> wrote:
>>>> 
>>>> 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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <aharui@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" <ha...@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
>>>>>>>>>>>>>> <ah...@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" <jo...@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
>>>>>>>>>>>>>>> <ah...@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" <ha...@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 <ha...@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 <ha...@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
>>>>>>>>>>>>>>>>>>>> <jo...@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" <ha...@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
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
> 


Re: [FlexJS] Use of typeof

Posted by Josh Tynjala <jo...@gmail.com>.
If you need access to global in Core, then yes, you should add node.swc.

The value of -targets does not determine which SWCs are included. It only
determines how the compiler generates the JavaScript. You should probably
continue to use JSFlex, but you should manually add node.swc to the
project's external-library-path. node.swc is only automatically included
when using the js/bin/asnodec compiler, which sets +configname=node and
that causes the compiler to load node-config.xml instead of the default
flex-config.xml.

Note that I'm not saying that you should try to use node-config.xml. I'm
just filling in some details on why changing -targets to JSNode didn't
work. You should add node.swc to the -external-library-path in the
project's compiler options.

- Josh

On Thu, Jul 13, 2017 at 10:04 AM, Harbs <ha...@gmail.com> wrote:

> Are you saying we should add node.swc to Core?
>
> FWIW, I just tried setting targets to JSNode and global is still not
> recognized. node.swc does not seem to be used even when that’s the target.
> That does not seem right either.
>
> > On Jul 13, 2017, at 7:42 PM, Josh Tynjala <jo...@gmail.com> wrote:
> >
> > I think the correct solution is to add node.swc to the
> > -external-library-path when you need access to global. You need js.swc on
> > the -external-library-path when you want to access window. You can't use
> > window in a SWF-only project, for instance.
> >
> > - Josh
> >
> > On Thu, Jul 13, 2017 at 9:29 AM, Harbs <ha...@gmail.com> wrote:
> >
> >> There is a mention of window in the NativeJSType enums. Not sure why
> it’s
> >> needed there.
> >>
> >> global should already be in node.js (I think). I’m pretty sure it’s
> >> defined in the node typedefs
> >>
> >> I don’t really care how it’s achieved, but by default (without doing any
> >> special imports) global should be recognized. (just like window is)
> >>
> >> Right now, typing global into a FlexJS project targeting “JSFlex” or any
> >> one of the framework projects results in a compiler error. How do we fix
> >> that?
> >>
> >>> On Jul 13, 2017, at 7:17 PM, Alex Harui <ah...@adobe.com.INVALID>
> >> wrote:
> >>>
> >>> 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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <aharui@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" <ha...@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
> <aharui@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" <ha...@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
> >>>>>>>>>>>>> <ah...@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" <jo...@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
> >>>>>>>>>>>>>> <ah...@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" <ha...@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.lists@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.lists@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
> >>>>>>>>>>>>>>>>>>> <jo...@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.lists@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
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
>
>

Re: [FlexJS] Use of typeof

Posted by Harbs <ha...@gmail.com>.
Are you saying we should add node.swc to Core?

FWIW, I just tried setting targets to JSNode and global is still not recognized. node.swc does not seem to be used even when that’s the target. That does not seem right either.

> On Jul 13, 2017, at 7:42 PM, Josh Tynjala <jo...@gmail.com> wrote:
> 
> I think the correct solution is to add node.swc to the
> -external-library-path when you need access to global. You need js.swc on
> the -external-library-path when you want to access window. You can't use
> window in a SWF-only project, for instance.
> 
> - Josh
> 
> On Thu, Jul 13, 2017 at 9:29 AM, Harbs <ha...@gmail.com> wrote:
> 
>> There is a mention of window in the NativeJSType enums. Not sure why it’s
>> needed there.
>> 
>> global should already be in node.js (I think). I’m pretty sure it’s
>> defined in the node typedefs
>> 
>> I don’t really care how it’s achieved, but by default (without doing any
>> special imports) global should be recognized. (just like window is)
>> 
>> Right now, typing global into a FlexJS project targeting “JSFlex” or any
>> one of the framework projects results in a compiler error. How do we fix
>> that?
>> 
>>> On Jul 13, 2017, at 7:17 PM, Alex Harui <ah...@adobe.com.INVALID>
>> wrote:
>>> 
>>> 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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <aharui@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" <ha...@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
>>>>>>>>>>>>> <ah...@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" <jo...@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
>>>>>>>>>>>>>> <ah...@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" <ha...@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 <ha...@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 <ha...@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
>>>>>>>>>>>>>>>>>>> <jo...@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" <ha...@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
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> 


Re: [FlexJS] Use of typeof

Posted by Josh Tynjala <jo...@gmail.com>.
I think the correct solution is to add node.swc to the
-external-library-path when you need access to global. You need js.swc on
the -external-library-path when you want to access window. You can't use
window in a SWF-only project, for instance.

- Josh

On Thu, Jul 13, 2017 at 9:29 AM, Harbs <ha...@gmail.com> wrote:

> There is a mention of window in the NativeJSType enums. Not sure why it’s
> needed there.
>
> global should already be in node.js (I think). I’m pretty sure it’s
> defined in the node typedefs
>
> I don’t really care how it’s achieved, but by default (without doing any
> special imports) global should be recognized. (just like window is)
>
> Right now, typing global into a FlexJS project targeting “JSFlex” or any
> one of the framework projects results in a compiler error. How do we fix
> that?
>
> > On Jul 13, 2017, at 7:17 PM, Alex Harui <ah...@adobe.com.INVALID>
> wrote:
> >
> > 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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <aharui@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" <ha...@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
> >>>>>>>>>>> <ah...@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" <jo...@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
> >>>>>>>>>>>> <ah...@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" <ha...@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 <ha...@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 <ha...@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
> >>>>>>>>>>>>>>>>> <jo...@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" <ha...@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
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
>

Re: [FlexJS] Use of typeof

Posted by Harbs <ha...@gmail.com>.
There is a mention of window in the NativeJSType enums. Not sure why it’s needed there.

global should already be in node.js (I think). I’m pretty sure it’s defined in the node typedefs

I don’t really care how it’s achieved, but by default (without doing any special imports) global should be recognized. (just like window is)

Right now, typing global into a FlexJS project targeting “JSFlex” or any one of the framework projects results in a compiler error. How do we fix that?

> On Jul 13, 2017, at 7:17 PM, Alex Harui <ah...@adobe.com.INVALID> wrote:
> 
> 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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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
>>>>>>>>>>> <ah...@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" <jo...@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
>>>>>>>>>>>> <ah...@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" <ha...@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 <ha...@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 <ha...@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
>>>>>>>>>>>>>>>>> <jo...@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" <ha...@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
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


Re: [FlexJS] Use of typeof

Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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
>>>>>>>>>><ah...@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" <jo...@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
>>>>>>>>>>> <ah...@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" <ha...@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 <ha...@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 <ha...@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
>>>>>>>>>>>>>>>> <jo...@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" <ha...@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
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>


Re: [FlexJS] Use of typeof

Posted by Harbs <ha...@gmail.com>.
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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <jo...@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
>>>>>>>>>> <ah...@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" <ha...@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 <ha...@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 <ha...@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
>>>>>>>>>>>>>>> <jo...@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" <ha...@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
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


Re: [FlexJS] Use of typeof

Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <jo...@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
>>>>>>>>> <ah...@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" <ha...@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 <ha...@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 <ha...@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
>>>>>>>>>>>>>> <jo...@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" <ha...@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
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>


Re: [FlexJS] Use of typeof

Posted by Harbs <ha...@gmail.com>.
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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <jo...@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
>>>>>>>> <ah...@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" <ha...@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 <ha...@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 <ha...@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
>>>>>>>>>>>>> <jo...@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" <ha...@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
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


Re: [FlexJS] Use of typeof

Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <jo...@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
>>>>>>> <ah...@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" <ha...@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 <ha...@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 <ha...@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
>>>>>>>>>>>><jo...@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" <ha...@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
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>


Re: [FlexJS] Use of typeof

Posted by Harbs <ha...@gmail.com>.
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 <ah...@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" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <jo...@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
>>>>>> <ah...@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" <ha...@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 <ha...@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 <ha...@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 <jo...@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" <ha...@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
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


Re: [FlexJS] Use of typeof

Posted by Alex Harui <ah...@adobe.com.INVALID>.
What AS do you want to write and what JS do you want as output?

-Alex

On 7/9/17, 12:53 AM, "Harbs" <ha...@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 <ah...@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" <ha...@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 <ah...@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" <jo...@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
>>>>><ah...@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" <ha...@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 <ha...@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 <ha...@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 <jo...@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" <ha...@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
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>> 
>> 
>


Re: [FlexJS] Use of typeof

Posted by Harbs <ha...@gmail.com>.
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 <ah...@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" <ha...@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 <ah...@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" <jo...@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 <ah...@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" <ha...@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 <ha...@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 <ha...@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 <jo...@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" <ha...@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
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>> 
>> 
> 


Re: [FlexJS] Use of typeof

Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@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 <ah...@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" <jo...@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 <ah...@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" <ha...@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 <ha...@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 <ha...@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 <jo...@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" <ha...@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
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>> 
>


Re: [FlexJS] Use of typeof

Posted by Harbs <ha...@gmail.com>.
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 <ah...@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" <jo...@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 <ah...@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" <ha...@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 <ha...@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 <ha...@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 <jo...@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" <ha...@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
>>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
> 


Re: [FlexJS] Use of typeof

Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <jo...@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 <ah...@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" <ha...@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 <ha...@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 <ha...@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 <jo...@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" <ha...@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
>> >>>
>> >>
>> >
>>
>>


Re: [FlexJS] Use of typeof

Posted by Josh Tynjala <jo...@gmail.com>.
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 <ah...@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" <ha...@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 <ha...@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 <ha...@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 <jo...@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" <ha...@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
> >>>
> >>
> >
>
>

Re: [FlexJS] Use of typeof

Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <ha...@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 <ha...@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 <ha...@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 <jo...@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" <ha...@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
>>> 
>> 
>


Re: [FlexJS] Use of typeof

Posted by Harbs <ha...@gmail.com>.
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 <ha...@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 <ha...@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 <jo...@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" <ha...@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
>> 
> 


Re: [FlexJS] Use of typeof

Posted by Harbs <ha...@gmail.com>.
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 <ha...@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 <jo...@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" <ha...@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
> 


Re: [FlexJS] Use of typeof

Posted by Harbs <ha...@gmail.com>.
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 <jo...@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" <ha...@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


Re: [FlexJS] Use of typeof

Posted by Josh Tynjala <jo...@gmail.com>.
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" <ha...@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