Both the old compiler and Falcon autogenerate plenty of code (for data binding, child creation, etc.) involving specific classes and interfaces from the SDK. I don't known whether these classes and interfaces have actually changed across versions of the SDK, but it's possible that they have. So I think we should consider the compiler and the SDK to be paired. Eliminating this pairing by autogenerating data which gets interpreted at runtime might or might not be a good idea, depending on the performance implications.
- Gordon > On Oct 3, 2014, at 8:08 AM, "Alex Harui" <aha...@adobe.com> wrote: > > > >> On 10/3/14, 2:39 AM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: >> >> If there is no strict link between compiler version an framework version >> ... would it actually be a good idea to have separate versioning for >> framework and compiler? > Falcon will probably have separate versioning. The first real release > will probably not be 4.x, but rather, 1.0. > > At one point, the goal was for Falcon to be more SDK-independent that > MXMLC. That was one of the reasons for compiler.mxml.children-as-data. > The less code generated by the compiler, the fewer SDK dependencies there > could be on that code. That was back when Falcon/ASC2.0 was to be bundled > in Flash Builder to be used for code intelligence. This is less a concern > for Apache Flex these days, so we don¹t have the same motivation for > Falcon to be SDK-independent, but IMO, since there are fewer > compiler-knowledgable people in the community, it still may be worth > finishing the children-as-data handling in Falcon and the SDK so that > future changes can be done in the SDK code. > > IIRC, there are subtle dependencies between MXMLC and the SDK it ships > with, but the short-term goal for Falcon is to get it to generate the same > code as MXMLC 4.6, and I don¹t believe Apache Flex has made any other > changes to MXMLC¹s generated code so I suspect that Falcon should work > with 4.6 and above. Then when that works, we can see about getting > compiler.mxml.children-as-data to have the same net effect. > > -Alex >
