I was thinking, maybe I'm not thinking in enough 5th dimensional thought here.
I'm not married to linked tokens, because other than Gordon helping
out I highly doubt I would even have time to implement that with the
current parser.
The code when parsed has insane AST source offsets to everything in
the actual source file. If we were "injecting" AST into a
class/method/etc., we would just basically be substringing it with a
replace. The code generation could be done already with the AS emitter
I have already made with FalconJx!
Holy #$%@! I think that might actually work! :)
Mike
Quoting Roland Zwaga <rol...@stackandheap.com>:
A writeable AST would be absolutely a must if we would ever want to
implement any kind of compile-time AOP functionality. So if that could be
done eventually, I think this would GREATLY improve the possibilities of
the compiler. (Not just from an AOP perspective, all sorts of compile-time
code generation could be added, I'm pretty sure Michael Labriola has a few
ideas for this :))
If somehow the compiler can be used through a ANE (AIR Native Extension)
than little apps like the one I made here with ASBlocks could become even
easier to build, plus the parsing times would become unnoticable.
I'll be happy to help out in these cases, so once you get around to it
let's brainstorm :)
Why couldn't it? I was thinking about that yesterday. It would be the data
exchange format that would have to be agreed upon, XML, binary? What do you
think. It would have to be something that the framework in asblocks could
easily decorate with it's existing API.
Well, I think the fastest communication protocol would actually be AMF. I
see no reason why an ANE couldn't send AMF back and forth. And all of the
serialization logic already exists for that, so implementing it should,
theoratically, be quite straightforward...
Like I said, when they designed Falcon they are not saving the token
stream like my parsers did which makes this whole, read, write edit A LOT
harder. Actually it's the edit that would be broken.
Hm, so getting Falcon to edit the locale file like my little app is doing
right now would be kind of hard to implement if I understand correctly?
With AOP (I'm not to versed on it) but it seems to me that would be easy
to add. Since altering AST during compile is just managing API addition and
updating. You are not worried about producing end product code that had the
exact same formatting as the original source code did. Which is when
editing is out of the question right now with the Falcon compiler.
Aha, yes, this is true, AOP would be just about injecting AST subtrees, but
also renaming stuff (methods, classes, etc). But indeed, there would be no
concern about formatting or whatever. An AOP extension could detect custom
metadata that identifies the pointcuts etc and performs the AST injections.
But for now, just concentrate on the JS and ASDoc parts. :)
I'm going to do some experiments, I'll let you know.
Sure, maybe I can eventually take one of your experiments and start work on
the AOP bits. Sounds like a plan :)
cheers,
Roland
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
