Alex, Speaking of marshal plan... any thoughts on how to deal with that going forward?
The test cases that Adobe used / uses to validate marshal plan architecture and compatibility are pretty important. Do the mustella tests cover that ground? -- Rick Winscot On Thursday, January 12, 2012 at 4:40 PM, Alex Harui wrote: > > > > On 1/12/12 3:58 AM, "David Arno" <da...@davidarno.org > (mailto: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 > >
