FYI,
The design can create javascript at ANY leaf node. This is the way I
designed it. I said bottom down, that is when compiling a compilation
unit you would;
visitor.visitCompilationUnit(compilationUnit);
You could also go;
visitor.visitIf(ifNode);
It would only produce the javascript for that if(){} block.
You could do fancy things with offset saving in javascript output if
you wanted incremental compiles, I don't see where you would need a
BURM.
BTW, look at the unit tests I have and this is exactly how I am
testing the visitors creating javascript.
Mike
Quoting Daniel Wasilewski <devudes...@gmail.com>:
I can see one adventage of BURM.
When you have an IDE and you expect to see changes in runtime live.
It will be always faster to go from particular leaf up to the root,
just to update small chunk, instead traversing entire tree. But in a
case when you just need to translate entire structure once... no way
BURM will be faster.
On 12/14/2012 6:43 PM, Michael Schmalle wrote:
Quoting Alex Harui <aha...@adobe.com>:
We are definitely in prototype/research mode and different
angles should be
investigated. The key to the "Apache Way" is that if we have to make
choices in deciding what to ship, it should be done on technical merit.
What context are you speaking from? compiler, js framework?
In theory, everything in Apache is decided on technical merit. If your
version of AS to JS turns out to be faster and easier to maintain, it will
win.
It will be interesting to figure out what to do if the BURM version is
significantly faster, but my gut says that won't be the case.
Here is my opinion. All compilers are recursive. The BURM uses
grammar to create a tree walker.
That reducer is traversing the tree from the leaf nodes up. What I
have written is a bottom down traverse.
What I am saying is that every node it visits in the walker, the
visit method knows EXACTLY what nodes are going to be traversed and
pushes the recursion down into the specific node.
The before and after strategies may add weight to how fast it's
traversing but if it was really an issue, we would get rid of them
and use the primary handler and do the before and after logic in
the visitor method.
As you can see right now, the before and after handlers are for
code clarity and convenience.
Like I said, I don't have enough experience to contribute to the
BURM impl with all that ABC stuff intermingled so I guess it will
be interesting if the prototype is a dog.
Mike
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
