On 9/4/13 10:20 AM, "Gordon Smith" <gosm...@adobe.com> wrote:
>> The current FB can't use Falcon > >By making a new flex-compiler-oem.jar based on Falcon, you could make FB >use Falcon to compile. But I don't think you'd get memory-resident data >structures, which was one of the main points of Falcon... I think with >the flex-compiler-oem.jar approach you'd be starting over with each >compilation, parsing files, parsing SWCs, building symbol tables. >(Darrell, am I wrong here?) When I looked, that interface appears to have the state-retention data structures in it. Whether we can hook into it somehow is a different question. > > >You definitely wouldn't get Falcon-based code hinting, and the data >structures of the old Code Model would be taking up memory. Yup, and the current ASC2.0 code model has some "bugs" that are now fixed in Falcon. There were a few AS constructs it didn't handle correctly. > >The point of Falcon was to have the code hinting and the compilation >share data structures that are resident in memory. We could punt on integration with FB entirely and just focus on Eclipse integration. The Randori folks integrated their fork of Falcon with IntelliJ. I don't now if Eclipse integration is harder. We could also investigate donating more FB code to Apache, but I don't know who'd work on it and the code I've seen seems overly complicated. This is too much work in an area I don't know anything about for me to take on in the short term, so I might settle for better "bolt-on" integration through external tools configs for the short term. But if anyone has time and interest, please forge ahead. -Alex
