On Thu, Jun 4, 2015 at 1:20 PM, Alex Harui <aha...@adobe.com> wrote:
>
>
> 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?
>
>
Ok, yeah that was ME, what about naming collisions? If they are in a
package during AS dev, there is no possible naming collisions with real AS
classes that might be local or root. If we put them in a package, the
compiler can boil them down to global during compile, this was the
JavaScript tags job.
> >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.
>
>
I am using the Rhino source code right now but the license says;
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
QDox is Apache 2.
https://github.com/paul-hammant/qdox
>
> >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.
>
Ok, I will leave that up to you.
>
> >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?
>
Yeah, I can do it through comments, but right now the damn ASDocTokenizer
is broken, so I don't have an nice clean way to parse the doc comments.
So what should I do? I really don't want to write a tokenizer by hand, a
waste of time. That is why I am using QDox, faking a Java class and adding
the comment, parse it voila, nice API to get the comment and tags.
Right now the whole 4 files parse and render takes less then a second with
also using QDox.
Mike
>
> -Alex
>
>
