Re: [FlexJS] Use of typeof

[Josh Tynjala]

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  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  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 
> 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  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 
> >>> 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"  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 
> >> 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"  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  >
>  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,
>  

Re: [FlexJS] Use of typeof

[Josh Tynjala]

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  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  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  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 
> >> 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"  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 
> > 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"  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 
> >>> 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 

Re: [FlexJS] Use of typeof

[Harbs]

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  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  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  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 
>>> 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"  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 
>> 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"  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 
 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"  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 

Re: [FlexJS] Use of typeof

[Harbs]

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  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  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 
>> 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"  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 
> 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"  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 
>>> 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"  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 
> 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"  wrote:
> 
>> Checking for window will work for Node, but it will not work for

Re: [FlexJS] Use of typeof

[Josh Tynjala]

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  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 
> 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"  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 
> >>> 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"  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 
> > 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"  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 
> >>> 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"  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 

Re: [FlexJS] Use of typeof

[Harbs]

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  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"  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 
>>> 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"  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 
> 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"  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 
>>> 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"  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 
> 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"  wrote:
> 
>> No. I 

Re: [FlexJS] Use of typeof

[Alex Harui]

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"  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 
>>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"  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 
 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"  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 
>> 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"  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 
 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"  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
>>
>> wrote:
>> 
>> Sure, I know it wouldn't work at runtime, but it sounded like
>> Harbs
>> couldn't even get the compiler to accept 

Re: [FlexJS] Use of typeof

[Harbs]

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  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"  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 
>>> 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"  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 
> 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"  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 
>>> 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"  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 
> 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 

Re: [FlexJS] Use of typeof

[Alex Harui]

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"  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 
>>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"  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 
 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"  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 
>> 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"  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 
 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"  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

Re: [FlexJS] Use of typeof

[Harbs]

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  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"  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 
>>> 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"  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 
> 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"  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 
>>> 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"  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
 
 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

Re: [FlexJS] Use of typeof

[Alex Harui]

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"  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 
>>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"  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 
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"  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 
>> 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"  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
>>> 
>>> 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"  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
> 

Re: [FlexJS] Use of typeof

[Alex Harui]

What AS do you want to write and what JS do you want as output?

-Alex

On 7/9/17, 12:53 AM, "Harbs"  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  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"  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 
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"  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
>
> 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"  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  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  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?
> 

Re: [FlexJS] Use of typeof

[Harbs]

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  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"  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  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"  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 
 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"  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  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  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 

Re: [FlexJS] Use of typeof

[Alex Harui]

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"  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  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"  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 
>>> 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"  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  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  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 
 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 

Re: [FlexJS] Use of typeof

[Harbs]

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  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"  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 
>> 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"  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  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  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 
>>> 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"  wrote:
>>> 
 I’m trying to figure out how to solve this dilemma:
 
 Browsers attach global variables to window.
 
 Node.js attaches globals to global.
 

Re: [FlexJS] Use of typeof

[Alex Harui]

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"  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 
>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"  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  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  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 
>> 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"  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

[Josh Tynjala]

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 
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"  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  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  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 
> 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"  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

[Alex Harui]

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"  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  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  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 
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"  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

[Harbs]

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  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  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  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"  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

[Harbs]

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  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  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"  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

[Harbs]

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  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"  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

[Josh Tynjala]

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"  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

[FlexJS] Use of typeof

[Harbs]

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