flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: ActionScript and Apache Flex
Date Thu, 12 Jan 2012 21:40:24 GMT

On 1/12/12 3:58 AM, "David Arno" <david@davidarno.org> wrote:

> Makes sense. As for performance issues, that's easy to predict. If we just
> want compile-time support for enums, private constructors, abstract methods
> and classes and the like, then none of them will have a significant impact
> on runtime performance. All will impact (at least slightly) on compilation
> times. Similarly, if we want runtime checking, then they'll have runtime
> performance impacts.
> I think all of: compiler-supported metadata, enums, private constructors,
> abstract classes and generics would be easy to implement, as none require
> special opcodes or do anything tricky with the VM. Other things (such as
> method overloading and multiple inheritance/traits) would be impractical to
> implement as the VM doesn't support them. Frustratingly though, until we get
> our hands on the source if Falcon compiler, knowing the scope of work of
> these tasks is difficult.
> David.
It is hard to say until we get going on it.  One of the gotchas around a lot
of these features is the ability to access properties and methods via
obj["foo"] instead of obj.foo and how you check for things like that.  You
also have to take into account loading other SWFs so you can't always just
optimize a single SWF.

My thoughts around overloading was to just decorate the names sort of how I
recall C++ does it.  I don't know how Java does it.  And overloading is the
only thing I feel we need because it is probably the best solution to
backwards compatibility across versions which is a must for many enterprise
apps.  Everything else is a nice-to have.  There are some pretty good
solutions out there without having those language features, but for sure,
our backward compatibility story using Marshall Plan is not a pretty good

Alex Harui
Flex SDK Team
Adobe Systems, Inc.

View raw message