On 7/27/16, 1:14 AM, "Harbs" <harbs.li...@gmail.com> wrote:
>I’m running into lots of issues with the fact that HTMLElementWrapper >extends Sprite. The underlying problem is because all the native Flash >properties and methods are being exposed to the compiler for all >sub-classed objects. > >For my port this is causing two issues: > >1. It’s hard to find all the dependancies on Flash. Ideally, I’d like to >base my components off FlexJS ones instead of Spark and native Flash ones >and have the compiler find the pieces I’m missing. This is not working >because a lot of pieces appear to the compiler as fine because Sprite is >the base class. > >2. I’m getting lots of conflicts with property and method names. This is >mostly happening with components which were based off of Spark, but I’m >getting lots of compiler errors where pieces are not marked as overrides. >They should not have to be marked as overrides because FlexJS does not >implement them, but Flash does. > >The third issue is related to code completion help. The user should not >get hints for Flash properties and methods because they will not work in >HTML. So we've tried wrapping Sprite instead of extending it and ran into other issues in that implementation. As I mentioned in another thread, wrapping Sprite doubles the number of objects and therefore adds runtime overhead to solve what are essentially author-time problems. So in this fork of this thread, I want to explore alternative solutions. 1. For this problem, I think you could compile your app against the "JS" SWCs. As a reminder, each SWC in FlexJS is actually two SWCs: one containing SWF code, and one containing JS-only APIs to be consumed by downstream SWCs. I think the "JS" SWCs do not have any Flash dependencies. The "JS" SWCs do have some non-SWF public APIs used for communicating internally, but it is probably important for you to know that before the cross-compile anyway. If you can get a clean compile (it won't run as a SWF for sure), then I think you can then switch back to the regular SWCs and get a runnable SWF. 2. I think the parser builds the AST without caring about overrides and override detection is done as the AST is being read. It might be possible for Falcon to auto generate the override if the base definition is a Flash definition. 3. Similar to 1, maybe the SDK should be set up with the JS SWCs by default and the SWF compiler could auto-swap in the SWCs for Flash when actually linking in code into the SWF. Also, we could just use [Exclude] metadata to hide the Flash APIs although apparently, not every IDE supports [Exclude] metadata. Thoughts? -Alex
