On 6/2/15, 10:38 AM, "Michael Schmalle" <teotigraphix...@gmail.com> wrote:
>A couple questions;
>
>1. It doesn't look like you have private fields implemented to be emitted
>in the constructor? private fileds are going to the prototype. For
>instance;
>
>private var explicitWidth:Number = NaN;
>
>to
>
>/**
>* @private
>* @type {number}
>*/
>this.explicitWidth_ = NaN;
>
>Is this something that needs to happen, UIBase is what I am testing.
We’ll have to see if Erik or others with more JS and Goog experience can
answer that. IIRC, in just vanilla JS, a private member would be on the
prototype and some other thing like an annotation would try to keep people
from using it outside the class via some compile-time checking. However,
this fails in surprising ways for any members whose initial values are not
scalars. For example:
private var children:Array = [];
If this becomes
/**
* @private
*/
MyClass.prototype.children = [];
Then all instances share the one array, which is undesirable. So,
initializing fields in the constructor can avoid that problem at the cost
of running the init for scalars where it doesn’t matter.
What I don’t know is if Google Closure Compiler or Library has other
expectations about jsdoc for private members and whether they can be on
the prototype or not. I think the Linter has busted me for trying to
declare uninitialized private members in the constructor, but I could be
wrong about that. When I hit stuff like that I just give it an initial
value and keep on going.
>
>2. Running into problems with interfaces, if we use DOM,
>HTMLElementWrapper.element needs to be Element not Object correct? If not,
>you don't key code completion in the IDE.
There are probably lots of places where the jsdoc annotation is Object
when it can be something more specific. A lot of the jsdoc I did was
early when I just needed to get the tools to stop complaining. So feel
free to tighten up the jsdoc and/or use a more specific type than Object.
>
>3. flexjs_wrapper can't exist on Element, it's not dynamic, does it nee to
>be dynamic or do we just use array access?
>
>this.element['flexjs_wrapper'] = this;
Ah yes, there are some places where we hack JS “classes”. I’m open to
ideas on what to do. Can we subclass Element and add flexjs_wrapper?
>
>4. For DOM elements and the closure compiler, does it expect type Element,
>for instance is below correct?
>
>/**
> * @expose
> * @type {Element}
> */
>org_apache_flex_core_UIBase.prototype.positioner;
Not sure what you mean by “expect”, but the code snippet should work.
>
>5. The API now needs to be yanked out of Core/as/src into another
>directory
>like Core/api/src, so the as Flash and as HTML ActionScript can share the
>same interfaces, correct? What would be the plan?
You know, I went and moved everything into up to 3 folders (as, js, asjs),
then found out that FB only supports one folder path per source attachment
for a SWC. So now, when debugging you sometimes have to switch source
attachments from as to asjs. So, I’m totally up for another folder
restructuring.
So, not sure what files need to be yanked out and shared, but seems like
we have 3 different classes of source files;
1) AS for Flash
2) AS for JS
3) AS for both Flash and JS
I wonder if we need to plan ahead for any JS source for something we need
to hack in that can’t be described in AS.
Anyway, do you happen to know how IJ associates source with SWCs for
debugging? FB would rather we put #1 and #3 in the same source folder,
but that makes describing what gets cross-compiled to JS more difficult.
We could make COMPJSC smarter and ignore files with some directive in it
so folks don’t need to keep adding to a list of files when adding new
files.
>
>Lots more but I thought I would start with this.
>
>So from my sketchy tests we have:
Freakin’ cool! FWIW, I implemented a custom asdoc @ keyword that
suppresses casting functions in the JS output. Search for @flexjsignore.
Kinda hacky but saves on some output code that doesn’t matter in the JS
world.
-Alex
