flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yishay Weiss <yishayj...@hotmail.com>
Subject RE: [FALCONJX][FLEXJS} SWF Subclass (and other) Overrides
Date Tue, 06 Dec 2016 07:41:26 GMT
Sounds good.

Will you be addressing code-hinting issues?

From: Alex Harui<mailto:aharui@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


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

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

So, in our base classes, we would want to write:

   override public function get parent():IParent


   override public function

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


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message