flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: [FlexJS] Use of typeof
Date Thu, 13 Jul 2017 07:29:12 GMT
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 <aharui@adobe.com.INVALID> wrote:
> 
> I'm still not clear what changes are needed.
> 
> Are you trying to access APIs that are global but not defined in JS.SWC or
> Node.SWC?  Otherwise, the APIs on window/global should be defined in those
> SWCs.
> 
> I'm not sure what the test case is supposed to look like.
> 
> Thanks,
> -Alex
> 
> On 7/13/17, 12:11 AM, "Harbs" <harbs.lists@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" <harbs.lists@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" <harbs.lists@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" <harbs.lists@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 <aharui@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" <joshtynjala@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
>>>>>>>>>> <aharui@adobe.com.invalid>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> What class in Core needs this dependency?  I
think one drawback
>>>>>>>>>>> is
>>>>>>>>>>> that
>>>>>>>>>>> users of that class will need to add node.swc
to their project
>>>>>>>>>>> dependencies.  But I don't think every consumer
of Core will
>>>>>>>>>>> need
>>>>>>>>>>> node.swc.
>>>>>>>>>>> 
>>>>>>>>>>> But first, why didn't window["process"] work?
 In theory Falcon
>>>>>>>>>>> will
>>>>>>>>>>> let
>>>>>>>>>>> you access anything off of window.  We could
also add global if
>>>>>>>>>>> we
>>>>>>>>>>> want.
>>>>>>>>>>> Or maybe we should only allow global and have
some bootstrap
>>>>>>>>>>> code
>>>>>>>>>>> that
>>>>>>>>>>> maps global to window?
>>>>>>>>>>> 
>>>>>>>>>>> -Alex
>>>>>>>>>>> 
>>>>>>>>>>> On 7/4/17, 2:09 PM, "Harbs" <harbs.lists@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
>>>>>>>>>>>>>>> <joshtynjala@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
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


Mime
View raw message