[Falcon][Discuss] Modularity, extensibility and configurability of the Falcon compiler framework
Good day to all of you :) Hold on, I think this is going to be a long message... Moving on from the latest discussion between Erik and Frank about the ideal implementation of AS->JS cross-compilation, I think its perhaps an interesting venture to talk a little bit about some possible changes we could make to Falcon itself. Let me preface this with giving my opinion about both Erik's and Frank's proposed solution. I believe both gentlemen know their business and are passionate about their respective solution. I'm not going to abuse this thread by choosing sides. I also believe the discussion actually shouldn't have to take place. I believe there should be place for both solutions so that potential users of Apache Flex can choose the output that best fits their project. For instance, Frank's solution might be interesting for folks who don't want to go through the process of installing Closure, or who simply don't like Closure (for whatever reason, valid or not). Whereas Erik's implementation might even make sense in a larger project where multiple parties are adding Javascript to a shared codebase, but all of them use different technologies to generate that Javascript. If all of them make sure that the JS they provide is in the form that Closure expects it, all of their output could be part of a larger build system that involves Closure at the end of the line. (Just thinking out loud here) So therefore I believe that both avenues need to be explored and quite probably both avenues ought to find their place in a future release of Apache Flex. Right, using this introduction I'd like to start some sort of discussion about the design of Falcon at the moment. (And what I understand of it at the moment, so Michael, Alex, Gordon, if I start talking out of m y a**, please correct me). Currently there seem to be three compilers: MXMLC, COMPC and ASC. All three (and now a fourth called 'ASJS' I guess) are a kind of monolithic class that creates all of its dependencies internally. So, if we want to compile mxml/as we invoke MXMLC and if we want to compile pure as3 we invoke ASC, etc. Come to think of it, there's even a fifth one, if we count Michael Schmalle's ASDoc compiler implementation. I think it might make more sense to create a single point of entry for all types of compilation. Let's call this point of entry FLEXC (credit: Michael Schmalle). Wouldn't it be cleaner to use this FLEXC compiler as a sort of factory for all the different types of compilers that make up the Falcon framework? FLEXC could use an XML configuration file that describes the various compilers and could create a fully configured instance. (Essentially FLEXC would be a specialised DI container for Falcon compilers). The XML configuration for FLEXC could look like this (very simplified): This way FLEXC could invoked with a *-swf* parameter so that FLEXC knows it has to return an instance of the swf target. All parameters coming *after* the *-swf* param would be ignored by FLEXC and instead passed on to the instance that it created. This way the frontends and/or backends could receive additional configuration: Obviously the configuration doesn't HAVE to be XML, I'm just using it as an example. So, by way of the configurability/modularity of Falcon and the examples above, I come to the notion of extensibility. Currently there is no plugin architecture in place in the Falcon framework (at least, not that I'm aware, please correct me if I'm wrong). Now, IMHO, things would become extremely interesting if we do identify a number of hooks into the compiler process where a potential plugin could add or manipulate functionality. In the best case, I even believe that ALL functionality should basically be viewed as pluggable. As the configuration example shows, in theory it ought to be possible to override the entire frontend and plug your own custom AS3 parser. (Not a lot of folks would choose to do so, but in the spirit of clean design I think it would make sense :)) Coming back to the case of Erik's and Frank's proposal of Javascript emission. If the Falcon backends will be designed (and I believe Michael Schmalle has already done so in his ASJS implementation) then we don't need to fight over which implementation Apache Flex should officially choose. Folks can build both and offer them to the Apache Flex community as a configurable option. I haven't looked very deeply into the ABC backend yet, so I have no clear picture how different Michael Schmalle's backend is from the ABC backend, but ideally there would be some consolidation between the two (if necessary). That way a standardized way of configuring the emitter implementations for a specific backend could be defined. (Because, if I recall correctly, currently Erik's and Frank's solutions are basically different implementations of an emitter, right?) As you can read in my example configuration, I also added this entry:
Re: [Falcon][Discuss] Modularity, extensibility and configurability of the Falcon compiler framework
+1 on this. FYI, As the Apache way suggests, itch your scratch... This one is going to happen and I will be working on it with Roland. We are looking for constructive criticism, not a blessing. :) I already have 2 compilers to work with and it's ridiculous one parse session can't be used for multiple targets, I think in a nut shell this is what Roland is getting at here. Yes, FLEXC rhymes with sexy. ;-) And this compiler frontend-backend will be sexy for sure. In the spirit of understanding, with a prototype we are going to develop it in a non intrusive way to the existing compilers. There is no plan to go hacking into the existing code if we don't have to at this point, plus that would be completely stupid IMHO. I think the proof of concept will use the FlaconJx and ASDoc compilers to prove our configuration concept, which verifies we will not touch the existing MXMLC or COMPC code for now. Mike Quoting Roland Zwaga : Good day to all of you :) Hold on, I think this is going to be a long message... Moving on from the latest discussion between Erik and Frank about the ideal implementation of AS->JS cross-compilation, I think its perhaps an interesting venture to talk a little bit about some possible changes we could make to Falcon itself. Let me preface this with giving my opinion about both Erik's and Frank's proposed solution. I believe both gentlemen know their business and are passionate about their respective solution. I'm not going to abuse this thread by choosing sides. I also believe the discussion actually shouldn't have to take place. I believe there should be place for both solutions so that potential users of Apache Flex can choose the output that best fits their project. For instance, Frank's solution might be interesting for folks who don't want to go through the process of installing Closure, or who simply don't like Closure (for whatever reason, valid or not). Whereas Erik's implementation might even make sense in a larger project where multiple parties are adding Javascript to a shared codebase, but all of them use different technologies to generate that Javascript. If all of them make sure that the JS they provide is in the form that Closure expects it, all of their output could be part of a larger build system that involves Closure at the end of the line. (Just thinking out loud here) So therefore I believe that both avenues need to be explored and quite probably both avenues ought to find their place in a future release of Apache Flex. Right, using this introduction I'd like to start some sort of discussion about the design of Falcon at the moment. (And what I understand of it at the moment, so Michael, Alex, Gordon, if I start talking out of m y a**, please correct me). Currently there seem to be three compilers: MXMLC, COMPC and ASC. All three (and now a fourth called 'ASJS' I guess) are a kind of monolithic class that creates all of its dependencies internally. So, if we want to compile mxml/as we invoke MXMLC and if we want to compile pure as3 we invoke ASC, etc. Come to think of it, there's even a fifth one, if we count Michael Schmalle's ASDoc compiler implementation. I think it might make more sense to create a single point of entry for all types of compilation. Let's call this point of entry FLEXC (credit: Michael Schmalle). Wouldn't it be cleaner to use this FLEXC compiler as a sort of factory for all the different types of compilers that make up the Falcon framework? FLEXC could use an XML configuration file that describes the various compilers and could create a fully configured instance. (Essentially FLEXC would be a specialised DI container for Falcon compilers). The XML configuration for FLEXC could look like this (very simplified): This way FLEXC could invoked with a *-swf* parameter so that FLEXC knows it has to return an instance of the swf target. All parameters coming *after* the *-swf* param would be ignored by FLEXC and instead passed on to the instance that it created. This way the frontends and/or backends could receive additional configuration: Obviously the configuration doesn't HAVE to be XML, I'm just using it as an example. So, by way of the configurability/modularity of Falcon and the examples above, I come to the notion of extensibility. Currently there is no plugin architecture in place in the Falcon framework (at least, not that I'm aware, please correct me if I'm wrong). Now, IMHO, things would become extremely interesting if we do identify a number of hooks into the compiler process where a potential plugin could add or manipulate functionality. In the best case, I even believe that ALL functionality should basically be viewed as pluggable. As the configuration example shows, in theory it ought to be possible to override the entire frontend and plug your own custom AS3 parser. (Not a lot of folks would choose to do so, but in the spirit of cle
Re: [Falcon][Discuss] Modularity, extensibility and configurability of the Falcon compiler framework
Roland, Me likey. Some comments and suggestions inline: > I think it might make more sense to create a single point of entry for all > types of compilation. Let's call this point of entry FLEXC (credit: > Michael Schmalle). Wouldn't it be cleaner to use this FLEXC compiler as a > sort of factory for all the different types of compilers that > make up the Falcon framework? FLEXC could use an XML configuration file > that describes the various compilers and could create > a fully configured instance. (Essentially FLEXC would be a specialised DI > container for Falcon compilers). Big +1 here. > So, by way of the configurability/modularity of Falcon and the examples > above, I come to the notion of extensibility. > Currently there is no plugin architecture in place in the Falcon framework > (at least, not that I'm aware, please correct me if I'm wrong). > ... > Coming back to the case of Erik's and Frank's proposal of Javascript > emission. If the Falcon backends will be designed (and I believe Michael > Schmalle has already done so in his ASJS implementation) then we don't need > to fight over which implementation Apache Flex should officially > choose. Folks can build both and offer them to the Apache Flex community as > a configurable option. > ... > for a specific backend could be defined. (Because, if I recall correctly, > currently Erik's and Frank's solutions are basically different > implementations of > an emitter, right?) This is pretty much how Mike set it up. The code for the emitters is really nicely compartmentalized and you can easily switch out the backend for another. After Mike helped me set up the Goog emitters and I got how it worked, it was really easy for me to start an AMD/RequireJS version, to help out Frank with his contribution. It's not quite abstracted to the level of a plugin structure, and it's beyond me to create that (I only started doing Java to help out Mike and implement Goog), but it certainly should be possible, IMHO. > I'd love to hear some opinions, so let the games begin :) In my opinion you've hit the nail on the head. Now all we need to do is to take it from theory to implementation, after we get all the compiler factions on the same page... Good luck ;-) EdB -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
RE: [Falcon][Discuss] Modularity, extensibility and configurability of the Falcon compiler framework
>In the spirit of understanding, with a prototype we are going to develop it in >a non intrusive way to the existing compilers. There is no plan to go hacking >into the existing code if we don't >have to at this point, plus that would be >completely stupid IMHO. > >I think the proof of concept will use the FlaconJx and ASDoc compilers to >prove our configuration concept, which verifies we will not touch the existing >MXMLC or COMPC code for now. > I am all about this. I already started porting all of Randori to AS and plan to check it in here in my whiteboard Right now we can't compile it with Falcon in a way that will run, but it is an excellent gap analysis of what I need to help write. Randori is about cross-compiled business logic, integrated with existing JS components and intrinsic Dependency Injection. We are deploying apps this way today but using C# as our source language. The apps work, and the approach works well. Ironically, the most difficult part is finding reasonable JS components that aren't full of coupling, but let's hope that these continue to evolve or some of the efforts here on Flex provide us with an excellent JS component set going forward. In either case, this is where I plan to spend my time, Mike
