flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: [FALCONJX][FLEXJS} SWF Subclass (and other) Overrides
Date Mon, 05 Dec 2016 18:51:02 GMT
I like.

On Dec 5, 2016, at 8:49 PM, Alex Harui <aharui@adobe.com> wrote:

> 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

View raw message