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-

Reply via email to