Sounds good.
Will you be addressing code-hinting issues? From: Alex Harui<mailto:aha...@adobe.com> Sent: Monday, December 5, 2016 8:50 PM To: dev@flex.apache.org<mailto:dev@flex.apache.org> Subject: [FALCONJX][FLEXJS} SWF Subclass (and other) Overrides Hi, I just pushed changes to allow certain kinds of overrides in SWF that normally aren't possible. The reasoning behind doing this is to allow us to have a library that extends SWF classes like Sprite but hide the flash APIs. For example, in Sprite, the parent property is defined as a flash.display.DisplayObjectContainer. In FlexJS, we would much rather use a non-Flash API like org.apache.flex.core.IParent, so a parent can be platform-agnostic. Similarly, the dispatchEvent API takes a flash.events.Event and it would be better to have it take an org.apache.flex.events.Event, or maybe an org.apache.flex.events.IFlexJSEvent. So, in our base classes, we would want to write: override public function get parent():IParent And override public function dispatchEvent(event:org.apache.flex.events.Event):Boolean But not only would the SWF compiler not allow that, the Flash runtime checks the type of any override at runtime and reports an error if there isn't a match (and such an issue would not be caught by the JS runtime). So to get this all to work, the compiler needs to know that certain type-mismatches are allowed, and also to restore the type to the original type in the SWF. To do so, I taught the compiler to look for a SWFOverride metadata that provides the original types for parameters or return values. When the compiler sees a mismatch, it checks for metadata allowing the mismatch. And when writing out the SWF, it also checks for the metadata and replaces the types in the ABC traits. So far, in minimal testing, it seems to work. Next up, after fixing a bunch of bugs in the queue, is to work on having the compiler generate both SWF and JS output in a single run. Then with proper overriding of various Flash APIs, we should be able to provide a more efficient way for FlexJS developers to see any conflicts with underlying platform implementations without having to wrap every implementation. Later, -Alex
