"In looking at the change in Falcon, it appears that the patch was required because the resolveBaseClass does not resolve to EventDispatcher. Did you look into trying to get resolveBaseClass to resolve to EventDispatcher. I'm wondering if there will be other issues related to that."
The change is more at the output stage rather than hacking the original AST to do that now. You know this far better than I do, but I don't *think* this should cause an issue in js because of the way the framework classes are always avalalable, but just thinking about it, perhaps for a simple AS project with a couple of Bindable classes, if the implicit implementation is created this may cause an issue in swf, because the baseclass EventDispatcher is now non-native - if the dependency is not addressed explicitly elsewhere in the swf - is that what you mean? I haven't tried anything like this, but I can check this first thing on Monday my time. "I'll see if I can reproduce." I think there was an example of this in the manualtests commit history of MyIntiialView On Sat, Sep 3, 2016 at 11:14 AM, Alex Harui <aha...@adobe.com> wrote: > > > On 9/2/16, 3:26 PM, "Greg Dove" <greg.d...@gmail.com> wrote: > > >Alex, I believe the last PRs I made across falcon and asjs address the > >various recent issues we discussed. > > Hi Greg, thanks for sticking with it. > > In looking at the change in Falcon, it appears that the patch was required > because the resolveBaseClass does not resolve to EventDispatcher. Did you > look into trying to get resolveBaseClass to resolve to EventDispatcher. > I'm wondering if there will be other issues related to that. > > > > >One additional (strange) thing I observed (partly because I was using a > >plain text editor at one point, without xml hinting) is that you can get a > >swf with invalid bytecode (stack overflow or underflow) by having bad xml > >in the mxml. > > I'll see if I can reproduce. > > -Alex > >
