Hi Alex, for me is difficult right now think about what would be better for TypeScript. I think all will depend on how people interact in the following months/years to show us what't the best for Royale in the long term. I think bringing TS to Royale as a first citizen language will make us more accesible and people will considere us more since TS is the language people choose over AS3 (although I for example like AS3 more and if we get few things like generics we'll be great to compete with TS), but this is a very complex task, so I know this hardly be done unless someone comes with time and knowledge to make it happen. And if we think about things that are complex and hard to add and see the importance/value it will bring to Royale I think a WebAssembly target will be over TS since it clearly enhance the Roayle purpose of generate multiple sources.
In the other hand, make TS just to do TypeDefs, again maybe users should express here if it could be needed, I can't say right now how much this could be important for Royale, so maybe time and users will let us know what to do. El jue., 2 may. 2019 a las 22:44, Alex Harui (<[email protected]>) escribió: > The word "package" has many meanings. In AS3 it is a way of avoiding API > name collisions. AIUI, an AS3 package in SWF code has no object or > function representation. It effectively just creates a longer "qualified > name". IOW, in a SWF, if there is a class "mx.core.UIComponent", there is > no "mx.core" object you can iterate to see all of the classes. > > For Royale's JS output, an AS3 package has an object representation in > debug mode because we use the same pattern as Google Closure. So there > really would be an "mx" Object with a "core" property object with a > UIComponent function that serves as the constructor. However, in > production, these package objects are often collapsed, so it is best to not > assume the objects exist. > > Then there are Node/NPM packages and modules and other sorts of > "packaging". But in this thread I was only referencing AS3 Packages. > > Also in this thread I mentioned TypeScript. While Royale could support > TypeScript as Carlos mentioned, as an alternative to writing AS3, I only > mentioned it because the existence of a TypeScript definition for a library > indicates that the library can have a strongly-typed API surface which > means it is highly likely you can create Royale typedefs for that library, > and because I thought that Josh's converter was still working. Supporting > TypeScript as an alternative programming language in Royale is a > significant chunk of work and is not something I plan to work on at this > time. But I was only mentioning using TypeScript to generate typedefs, > which is a different effort and could be a smaller effort and give us > access to a huge set of typedefs. I have no plans to work on that at this > time either, but I could imagine myself working on that if there was enough > demand for it. > > HTH, > -Alex > > On 5/2/19, 11:24 AM, "Dany Dhondt" <[email protected]> wrote: > > Hi Josh, > > Aren’t most of the packages just functions? > In ES6, you’d import packages as > Import { myFunct, myVar } from ‘my-package’ > In older javascript you’d: > const myPackagePointer = require(‘my-package’) > > So your ‘fun’ example sounds like heaven to me! This is exactly what > we need. > > About Typescript: do we need that at all? I think, but maybe this goes > beyond my technical knowledge, all node packages are compiled into plain > old javascript functions. Typescript is only needed for authoring the > packages. Once compiled there’s no trace of Typescript at all. If this is > indeed true, then we shouldn’t bother about Typescript at all, and just > concentrate on incorporating the pure javascript libs. > > Dany > > > Op 2 mei 2019, om 19:57 heeft Josh Tynjala <[email protected]> > het volgende geschreven: > > > > Just for fun, here's another way that you could create a typedef for > hljs so that the highlightBlock() function is directly in a package > (similar to flash.net.navigateToURL), instead of as a static method on a > class: > > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FkhVI&data=02%7C01%7Caharui%40adobe.com%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=IADdFIV05gFba9voojnIWzJOCimRR%2F0dp4fgneKs9xM%3D&reserved=0 > > > > If you did it this way, you'd need to import it before you can call > the function, like this: > > > > import hljs.highlightBlock; > > > > Or this should work too, if you prefer: > > > > import hljs.*; > > > > And then you can call the function directly (without the hljs. > prefix): > > > > highlightBlock(block); > > > > As you can see, the way that you choose to expose a JS library to > ActionScript is pretty flexible. Some JavaScript libraries are just a > function, and some have APIs that work more like classes. Depending on the > library, one way may work better than the other. > > > > - Josh > > > > On 2019/05/02 17:48:49, Josh Tynjala <[email protected]> > wrote: > >> Exactly right. When you create a typedef class, you're trying to > simulate how you would access the API as if you were writing in plain > JavaScript. You call hljs.highlightBlock() in JavaScript, so you need a > class that works the same way in ActionScript. > >> > >> Another option for organization would be to keep all of your > typedefs in a separate folder from your app's source files, and reference > the typedefs folder using the source-path compiler option. > >> > >> - Josh > >> > >> On 2019/05/02 16:23:45, Alex Harui <[email protected]> > wrote: > >>> Hi Carlos, > >>> > >>> I don’t think hljs is in a package called "externs". In Josh's > example, hljs was in the top-level package. And that's because hljs is > found at runtime off of the global window object, not some sub-object > called "externs". So, the hljs.as file containing the externs has to go > in the root of a source-path, not in some folder called "externs" (which is > why some folks will take the time to create a separate typedefs SWC so as > not to clutter the root of their application's source directory). > >>> > >>> Then instead of "import externs.hljs", it should be "import hljs" > (or shouldn’t be needed at all). > >>> > >>> HTH, > >>> -Alex > >>> > >>> On 5/2/19, 9:11 AM, "Carlos Rovira" <[email protected]> > wrote: > >>> > >>> Hi, > >>> > >>> in my latest commit I added hljs extern class like Josh show in > package > >>> externs in TDJ > >>> > >>> Then I didn't commit the following since is not working for me: > >>> > >>> 1.- In HighlightCode class (in utils package TDJ) > >>> > >>> added: > >>> > >>> import externs.hljs; > >>> > >>> changed the method highlightBlock to: > >>> > >>> COMPILE::JS > >>> /** > >>> * block is the element (WrappedHTMLElement) inside the > component (the > >>> <code> tag) > >>> */ > >>> public function highlightBlock(block:Element):void > >>> { > >>> hljs.highlightBlock(block); > >>> } > >>> > >>> and running it I get: > >>> > >>> Uncaught ReferenceError: externs is not defined > >>> at utils.HighlightCode.highlightBlock (HighlightCode.as:53) > >>> at > >>> > WelcomeSection.components.ExampleAndSourceCodeTabbedSectionContent.dataReadyHandler > >>> (ExampleAndSourceCodeTabbedSectionContent.as:138) > >>> at > services.GitHubService.goog.events.EventTarget.fireListeners > >>> (eventtarget.js:284) > >>> at Function.goog.events.EventTarget.dispatchEventInternal_ > >>> (eventtarget.js:381) > >>> at > services.GitHubService.goog.events.EventTarget.dispatchEvent > >>> (eventtarget.js:196) > >>> at > >>> services.GitHubService.org > .apache.royale.events.EventDispatcher.dispatchEvent > >>> (EventDispatcher.js:71) > >>> at > services.GitHubService.services_GitHubService_completeHandler > >>> (GitHubService.as:54) > >>> at > >>> org.apache.royale.net > .HTTPService.goog.events.EventTarget.fireListeners > >>> (eventtarget.js:284) > >>> at Function.goog.events.EventTarget.dispatchEventInternal_ > >>> (eventtarget.js:381) > >>> at > >>> org.apache.royale.net > .HTTPService.goog.events.EventTarget.dispatchEvent > >>> (eventtarget.js:196) > >>> > >>> What I'm doing wrong? > >>> > >>> thanks! > >>> > >>> > >>> El jue., 2 may. 2019 a las 18:02, Carlos Rovira (< > [email protected]>) > >>> escribió: > >>> > >>>> Hi Josh, > >>>> > >>>> I think this piece of knowledge you just exposed here is key for > the > >>>> success of Royale. > >>>> > >>>> I'll try to use this in TDJ to experiment with it and will use in > the blog > >>>> example I plan to do. > >>>> > >>>> thanks! > >>>> > >>>> > >>>> El jue., 2 may. 2019 a las 16:36, Josh Tynjala (< > [email protected]>) > >>>> escribió: > >>>> > >>>>>> Users can't do this, they required that Royale framework devs > add > >>>>> typedefs to the typedefs repo and wait to next SDK release. What > does not > >>>>> seems very useful. > >>>>> > >>>>> Users can create their own typedefs from scratch. > >>>>> > >>>>> I just created a quick example for hljs, that exposes the > >>>>> highlightBlock() function: > >>>>> > >>>>> > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FdIq0&data=02%7C01%7Caharui%40adobe.com%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=PAmxrfMPo8lAt3tdyntHVlJ%2Bbk3F%2FWioTvjN7iRYSgw%3D&reserved=0 > >>>>> > >>>>> Basically, the class needs an asdoc comment with the @externs > tag (this > >>>>> is something that comes from Google Closure compiler, which we > use to > >>>>> create release builds) and the compiler should handle the rest. > >>>>> > >>>>> As I understand it, you don't even need to create a SWC library > for > >>>>> custom typedefs. Recently, Alex mentioned that the mxmlc > compiler is smart > >>>>> enough to handle a source file as long as it has the @externs > tag. > >>>>> > >>>>> - Josh > >>>>> > >>>>> On 2019/05/02 09:34:37, Carlos Rovira <[email protected]> > wrote: > >>>>>> Hi, > >>>>>> > >>>>>> to sumarize (let me know if I'm wrong), the current ways to > integrate an > >>>>>> existing library are 3: > >>>>>> > >>>>>> 1.- access vía brackets notation: This is the most easy and > direct, an > >>>>>> example is TourDeJewel in class utils.HighlightCode > >>>>>> > >>>>>> var hljs:Object = window["hljs"]; > >>>>>> hljs["highlightBlock"](block); > >>>>>> > >>>>>> but this one is not what we really want since we are going with > Roayle > >>>>> and > >>>>>> AS3 to get type checking and strong typing. So this, although > useful is > >>>>> not > >>>>>> what we really want to use in out Apps, but since we want to > maintain > >>>>> the > >>>>>> dynamic aspect of the language it could be very useful sometimes > >>>>>> > >>>>>> 2.- using typedefs > >>>>>> > >>>>>> This will be the next step to use a real type and dot notation, > but > >>>>> seems > >>>>>> not easy or direct. > >>>>>> Users can't do this, they required that Royale framework devs > add > >>>>> typedefs > >>>>>> to the typedefs repo and wait to next SDK release. What does > not seems > >>>>> very > >>>>>> useful. > >>>>>> > >>>>>> In the other hand we'll need to know how to extend current > typedefs > >>>>> since > >>>>>> don't know if we have docs about this. Until now I added to > "missing.js" > >>>>>> file fo now, but this doesn't seems a valid path since it lacks > >>>>>> organization, separation, and a way for all people contributing > to know > >>>>> wha > >>>>>> we have, what can be added and where, if not we'll find in time > lots of > >>>>>> code very difficult to maintain. > >>>>>> > >>>>>> Yishay and Josh talked about to use TypeScript, but seems that > is > >>>>> already > >>>>>> explored by Josh but not a valid path since will be very > difficult to > >>>>>> maintain. > >>>>>> > >>>>>> 3.- wrapping libraries > >>>>>> > >>>>>> This is how we did with MDL. This will be recommended when we > want to > >>>>>> integrate existing libraries with Royale to make it work with > our APIs > >>>>> in a > >>>>>> more seamless way. But the problems is that this is very > laborious. Can > >>>>> be > >>>>>> useful for some concrete libraries and we should do when needed > (the > >>>>> case > >>>>>> is MDL). But the problem is that this not solve the problem of > our users > >>>>>> that need to integrate a existing library themselves in a quick > way. > >>>>>> > >>>>>> Let me know if you know other way. > >>>>>> > >>>>>> For me method 1, is ok to do the work, but doesn't make us > justice. > >>>>>> method 2 should be the main one if there's a fast and easy > way... I'm > >>>>>> missing something here? Can users create typedefs themselves? > >>>>>> method 3 can be useful for us or for users (doing their own > libs, and > >>>>>> eventually can share with us to add to official royale repo and > sdk) > >>>>>> but is something not fast at all and not as convenient and > direct as > >>>>> method > >>>>>> 2, and will require maintenance as libs change. > >>>>>> > >>>>>> Could we agree that this is the currently available ways in > Royale now > >>>>> to > >>>>>> use external JS libs? > >>>>>> > >>>>>> thanks > >>>>>> > >>>>>> -- > >>>>>> Carlos Rovira > >>>>>> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=ogC7DNs6k8%2Bf4NUBRt6g5mFHTfa8Sk6W8gS%2FgnAiKqs%3D&reserved=0 > >>>>>> > >>>>> > >>>> > >>>> > >>>> -- > >>>> Carlos Rovira > >>>> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=ogC7DNs6k8%2Bf4NUBRt6g5mFHTfa8Sk6W8gS%2FgnAiKqs%3D&reserved=0 > >>>> > >>>> > >>> > >>> -- > >>> Carlos Rovira > >>> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0273d2643f2a4f40387208d6cf2b6539%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636924182624867437&sdata=ogC7DNs6k8%2Bf4NUBRt6g5mFHTfa8Sk6W8gS%2FgnAiKqs%3D&reserved=0 > >>> > >>> > >>> > >> > > > > -- Carlos Rovira http://about.me/carlosrovira
