> 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.
I would be happy to anwser but I'm not sure I understood the question.
If you add a SDK, SWC or a folder with SWCs and sources, it will scan and
detect swc and sources, for example, for the FlexJS folder imported as a lib,
it detects AS and ASJS for each swc, you can manualy add some source folders
for any of the SWCs.
When it comes to debug, I guess it asks FDB for the source file, it the file is
not referenced, it will show a native representation where you can still
associate sources.
Is that what you want to know ?
Frédéric THOMAS
> From: aha...@adobe.com
> To: dev@flex.apache.org
> Subject: Re: [FalconJX] FlexJS as to js work
> Date: Tue, 2 Jun 2015 18:15:20 +0000
>
>
>
> 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
>
