Hi Mike, I've been hacking away at CoreMedia's Hackathon today, so sorry for the late response.
On Thu, Feb 7, 2013 at 1:17 PM, Michael Schmalle <apa...@teotigraphix.com>wrote: > - What do you do with the !native stuff? I have those being tracked now > based on an enum I made from your repo > > - Where is your 'toplevel' list that is being included right now? IE trace > and what else? > These two questions are connected. I provide the compiler with an ActionScript API of those built-in classes, which can be found here<https://github.com/CoreMedia/jangaroo-tools/tree/jangaroo-3/jangaroo/jangaroo-runtime/src/main/joo> (general classes/functions/objects) and here<https://github.com/CoreMedia/jangaroo-libs/tree/jangaroo-3/jangaroo-browser/src/main/joo>(browser classes/functions/objects). All classes/functions/objects are annotated as [Native], which means that the compiler should not generate any JavaScript code for them, *but* it has an effect on what code is generated from a "real" ActionScript class that uses this [Native] class. So when an AS3 class references a class that the compiler parses and notices it is [Native], it generates a different require-reference to it, according to the rules I gave in a previous mail in this thread (or the other thread?). The "native!" RequireJS plugin takes care of retrieving JavaScript global objects, and, in case the browser does not support them (mostly IE8), load a "polyfill" script. The summary of how to map [Native] annotations to require-references is: - package bar [Native] class Foo -- "native!bar.Foo" - package bar [Native(global="baz.Faz")] class Foo -- "native!baz.Faz" - package bar [Native(amd)] class Foo -- "classes/bar/Foo" - package bar [Native(amd="baz/Foo")] class Foo -- "baz/Foo" - package bar [Native(amd="baz/Foo", global="baz.Faz")] class Foo -- "native!baz.Faz@baz/Foo" In any case, the resulting variable must *not* be de-referenced like AS3 compilation units, so no (Foo._ || Foo._$get()). The rules behind this are: - if there is no "amd" and no "global" attribute, the JavaScript object has the same fully qualified name as the ActionScript API and must be provided by the environment. - if there is a "global" parameter, use this as the fully qualified name of the JavaScript object (alias). - if there is an "amd" parameter and no "global" parameter, always load the given AMD module when this ActionScript API is required (in this case, [Native] just means "do not de-reference, its the class, not a compilation unit!"). - if there is an "amd" parameter *and* a "global" parameter, try to retrieve the global JavaScript object and only load the AMD module if the JavaScript object is not defined. The module must take care of defining the global JavaScript object, so the second try after loading the module succeeds. Thus the [Native] annotation can be used to declare ActionScript API for - built-in global JavaScript objects - JavaScript objects that are present in some environments but may have to be "polyfilled" by loading a script - global JavaScript objects defined by some JavaScript library If you think naming the attribute "script" instead of "amd", let me know. I just thought that we could The idea of the "native!" RequireJS plugin is that it is the most consequent way to avoid references to global, namespaced JavaScript objects throughout the code, which allows short local variable names (just "TextField" instead of "Ext.form.TextField") which can even be further shortened by the JavaScript minifier (in contrast to global names, which would need certain annotations like those GCC uses). Also it makes lookup a tiny bit faster, because the JS engine needs to go up one scope less. > > - Why is static bar in class A named 'bar' but static nowPlusOne in class > B is name 'nowPlusOne#static', what is the difference? > > This is just a glitch I did when inlining the functions from the Jangaroo output. The member functions do not need a name at all for the code to work. The only purpose is that stack traces look much nicer when functions have names, but some debuggers are even so intelligent to find out the name of the property the function has been assigned to. In Jangaroo, I postfixed static member variables (not their property names!) with "$static", because in AS3, there can actually be a non-static and a static member of the same name in the same class, and I wanted to avoid this name clash. Since we inline those member variables in FalconJx, you do not have to care about that problem. > - Can you point me to where you document this 'this.barfoo = (A._ || > A._$get()).bar(3);' > - specifically the '(A._ || A._$get())' > It's on the Wiki page: Compilation Units | Implementation Solution: Non-ES5 Browser Issues Since for the time being, we still target Internet Explorer 8 (or even 7), we need a solution that also works without get properties, so we need a more sophisticated solution for the _ property. In order not to always need to perform a function call (which results in a runtime penalty and is distracting during debugging), we try to read the field first and only call the function in case the property is not yet defined. Following the general pattern of naming explicit get functions (see below), the factory function for IE8 would be called _$get, resulting in the following expression to access a class from potentially not-yet-initialized compilation unit: (OtherClass_._ || OtherClass_._$get()) > > > As far as the unit testing, don't have an answer at the moment. > As you say, first things first! :-) Greetings -Frank-