On 9/2/16, 4:30 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>"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. In looking more closely at these changes, one of the changes removed code from ASCompilationUnit that set the base class to EventDispatcher. I hadn't realized that code wasn't replaced elsewhere, but it seems like hacking the AST to set the base class would have also fixed the last two issues (the missing goog.require and the missing @extends). So now I'm more curious about why you chose to move the logic to ClassDirectiveProcessor, and that further makes me wonder if we just haven't noticed some other ramification of not hacking the AST. We can continue this on Monday, no hurry. Thanks, -Alex
