> 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
