On 6/4/15, 9:53 AM, "Michael Schmalle" <teotigraphix...@gmail.com> wrote:
>Yeah to be honest my main concern was these SWCs. When I started testing
>the emitter for DOM stuff like I showed the other day, I couldn't
>"believe"
>in it because I was using the Randori stuff.
>
>Now with this, the first step is actually real and under the project's
>control, all of it.
>
>1. I'm going to use packages, what should the package be for the DOM.swc
>and JS.swc(was builtin.swc)?
If you mean the AS package for the classes in these SWCs, I have to admit
I was a bit surprised to see in the AS output example that Document in a
“dom” package. I would think these two SWCs would not have their classes
in any AS package (IOW, “package {“). Aren’t classes like Document
effectively global just like Math?
>2. I am using Rhino and QDox(hack for getting an easy parser for the
>jsdocs), so I guess a download jar entry is going to have to be added to
>the build script? I am not good at ant.
Rhino 1.74 or later is MPL. If we don’t need an earlier version then yes
we can download it and Qdox (which is AL). Just check in code that uses
these jars (but not the jars) and I’ll get the build scripts to download
them.
>3. How is the source files going to be handled for the extern files?
>Download them during build and then run the tool?
IMO, yes. But we might bundle them in the source release package.
>4. I think I am going to utilize that JavaScript metadata tag for these so
>it's easy to resolve stuff during compile.
I guess that’s ok with me. Why do you not want to introduce new metadata
keywords and/or use asdoc similar to how goog is using jsdoc? I’d worry
about a JavaScript metadata statement getting longer and longer as we add
more attributes to it. Having each attribute be a keyword or asdoc/jsdoc
tag seems like it would be more manageable?
-Alex
