On 1/17/12 11:59 PM, "David Arno" <da...@davidarno.org> wrote:
>
> The more I read about Falcon, the more concerned I become about it. I don't
> like the idea that we will have to wait six months for a half-working
> compiler, presumably with no APIs, documentation etc provided beforehand.
> There is huge risks associated with this: there is a great danger that we
> will lose too much community momentum in that time and we would have to put
> a great deal of trust into Adobe to deliver during a period of significant
> upheaval and ventures into the unknown..
Well, I guess you can say it will be "half-working", but really, the AS
portion should be fully working, and the MXML portion should be working for
simple cases.
I suppose Apache Flex has the option of writing its own MXML-to-AS front
end, but I'm not sure that will perform as well. Falcon goes MXML-to-ABC
and I believe that is one of the reasons it is faster. For us to start from
scratch and not leverage the finished AS work would probably still take
longer. I will say, though, that the MXML portion of Falcon is still
generating MX- and Spark-specific code. An alternative plan would be to
alter the SDK code to handle a single kind of codegen. That would make MXML
compiling simpler and potentially faster, but isn't backward-compatible and
could break some apps.
>
> Should we just ignore Falcon and instead consider a major overhaul of mxmlc,
> or even a completely new compiler? I guess it depends on how long we have to
> wait to get access to the mxmlc source and docs as to what the best way
> forward is.
I was in the Falcon code in November. It was way easier to figure out how
to make changes than with MXMLC. Even if it is not documented, I think it
will be easier to make progress that with the Falcon code base.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
