On 1/12/12 3:58 AM, "David Arno" <da...@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
solution.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
