On Thu, Jun 4, 2015 at 2:11 PM, Alex Harui <aha...@adobe.com> wrote:
>
>
> On 6/4/15, 10:31 AM, "Michael Schmalle" <teotigraphix...@gmail.com> wrote:
> >>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.
> >
>
> Do you mean a collision with some customer’s Document class in the
> top-level package? Wouldn’t that collision eventually cause something to
> break when the customer tries to run the output JS? Seems like getting
> AmbiguousReference would be a good thing.
>
>
DUH! It's the simple things I miss.
> >
> >
> >> >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/.
>
> Apache prefers to work with MPL from jars so I’ll pull a Rhino jar from
> somewhere.
>
>
OK
> >>
> >> >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.
>
> Hmm. Maybe I should spend some time looking into fixing ASDocTokenizer?
> Was the problem that it didn’t work on every AS file we current have?
>
It doesn't work on anything, there is an infinite loop in the scanner that
is created by JFlex, the RawASDocTokenizer is broken.
What is weird is I was using the SAME code base when I wrote the asdoc
documenter I have 2 years ago and it worked fine.
Mike
>
> -Alex
>
>
>
