On 2/5/13 8:25 AM, "Roland Zwaga" <rol...@stackandheap.com> wrote:
> I was just wondering about some of the implications.
> Imagine the case where we add language features and folks try to compile
> these
> using ASC2.0, they would get errors naturally. I'm guessing these folks
> would be
> confused by this, since they are under the impression that they're coding in
> AS3, and ASC2.0 is an AS3 compiler. (Says so on the box :))
Well, I guess that's valid, but a couple of poinfs:
1) That's already the case. ASC2.0 will not compile the Flex SDK. It turns
out there are syntax errors that MXMLC did not catch that ASC2.0 will.
2) IMO, 99% of folks using Flex will use MXML which ASC2.0 does not handle.
Also, IMO, I'm not clear these new language features, whenever the actually
happen, are going to be applied to the current SDK. There are backward
compatibility issues with the APIs, and I'm not sure how many folks will be
doing new work against the current SDK at that point in the future.
Furthermore, I am not clear that better type information in the language
would truly work against the current SDK. The current API has too many
places where things are typed as Object or "*". This may force you to use
the Vector() function to "coerce" back to the typed vector, and I believe
that is a costly thing to do in the current VM. IIRC, type-casting in AS3
is really a function call (that I think for Vector visits every element),
not a compiler thing.
In the new framework I'm prototyping I've played around with different APIs
that allow you to better maintain strong-typing throughout your code. If
you look at the List class I checked in recently in the ASJS branch, the
data model is a "bead" (plug-in) that you can access directly. This means
you could swap in different data models to directly support the type of your
data.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
