In browsers, globals are always stored on window. Basically, being able to reference them without first referencing window is a convenience.
In Node.js, window doesn't exist, though. I believe there's a separate global object, but it's not the default scope in the same way (the current module's scope is the default scope). So, basically, this trick only works in the browser. - Josh On Mon, Nov 7, 2016 at 2:51 PM, Harbs <[email protected]> wrote: > Wadayaknow? > > You’re right. It works without “window”. That should do the trick. > > Any clue on why that works? Does the JS engine check window if a global is > not defined? > > On Nov 8, 2016, at 12:44 AM, Harbs <[email protected]> wrote: > > > I’m pretty sure window is required here, but I’ll check. > > > > On Nov 8, 2016, at 12:21 AM, Josh Tynjala <[email protected]> wrote: > > > >> You can usually omit "window." in JS code. > >> > >> cep.fs.makedir(myPath) should work. > >> > >> - Josh > >> > >> On Mon, Nov 7, 2016 at 2:17 PM, Harbs <[email protected]> wrote: > >> > >>> How does that let you use something like this > >>> window.cep.fs.makedir(myPath)? > >>> > >>> Defining the type definitions is not the issue. > >>> > >>> On Nov 8, 2016, at 12:03 AM, Alex Harui <[email protected]> wrote: > >>> > >>>> > >>>> > >>>> On 11/7/16, 1:54 PM, "Harbs" <[email protected]> wrote: > >>>> > >>>>> I described CEP in my response which I just sent. > >>>>> > >>>>> CEP adds a number of global “classes" (such as CSInterface, CSEvent, > >>>>> Vulcan, etc.) It also has a built in Node environment, so you can use > >>>>> require(), Buffer, etc. > >>>>> > >>>>> These features are all easily handled by typedefs. > >>>>> > >>>>> The only sticky one is the “cep” object which is attached to window > >>>>> automatically by Adobe. This prompted my question. > >>>> > >>>> Why can't you do roughly what JQuery's typedefs do? Jquery looks > like: > >>>> > >>>> /** > >>>> * @constructor > >>>> */ > >>>> function jQuery(arg1, arg2) {} > >>>> > >>>> /** > >>>> * @const > >>>> * @type {!jQuery} > >>>> */ > >>>> var $ = jQuery; > >>>> > >>>> /** > >>>> */ > >>>> jQuery.prototype.add = function(arg1, context) {}; > >>>> > >>>> So wouldn't CEP look like: > >>>> > >>>> > >>>> /** > >>>> * @constructor > >>>> */ > >>>> function CEP(arg1, arg2) {} > >>>> > >>>> /** > >>>> * @const > >>>> * @type {!CEP} > >>>> */ > >>>> var cep = CEP; > >>>> > >>>> /** > >>>> */ > >>>> CEP.prototype.add = function(arg1, context) {}; > >>>> > >>>> -Alex > >>>> > >>>> > >>>> > >>>>> > >>>>> On Nov 7, 2016, at 11:47 PM, Alex Harui <[email protected]> wrote: > >>>>> > >>>>>> > >>>>>> > >>>>>> On 11/7/16, 1:37 PM, "Josh Tynjala" <[email protected]> wrote: > >>>>>> > >>>>>>> As far as I know, there's no way to do it without compiling a new > SWC > >>>>>>> using > >>>>>>> the sources from js.swc and including your additional APIs. > >>>>>>> > >>>>>>> That's not necessarily a bad thing. In fact, I'd say it's a best > >>>>>>> practice. > >>>>>>> Ideally, I would have built node.swc to also include a subset of > >>>>>>> what's in > >>>>>>> js.swc, instead of also including js.swc. Using js.swc for Node.js > >>> apps > >>>>>>> exposes a bunch of classes that don't actually exist in Node.js. I > >>>>>>> hope to > >>>>>>> clean that up eventually. This Adobe CEP sounds like a similar > >>>>>>> situation. > >>>>>>> It's a different environment, even if there's a lot of overlap. > >>>>>> > >>>>>> Is CEP a different environment, or just a new feature? I agree > about > >>>>>> Node > >>>>>> being a different environment. On the other hand, Cordova is a new > >>>>>> feature added to a browser, so there is a separate cordova.swc that > you > >>>>>> use along with js.swc. > >>>>>> > >>>>>> I think the first decision is what you want the API to look like. > Is > >>>>>> cep > >>>>>> a singleton? Or an instance of something? > >>>>>> > >>>>>> -Alex > >>>>>> > >>>>> > >>>> > >>> > >>> > > > >
