Like I mentioned in the other thread, it’s NOT just an author-time problem.
Conflicts in variables and methods will cause Flash runtime errors and override can often not be done properly. The only runtime workaround I can see for that would be to automatically rename the methods and properties, but that seem like a poor solution to me. On Aug 18, 2016, at 9:53 PM, Alex Harui <aha...@adobe.com> wrote: > > > 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
