Well I don't have any objections to leaving it in ... I just noticed that it definitely needs some hardening against NPEs. I was just assuming that the code could be removed as it didn't have any effect on the Falcon output. But I'm totally fine with leaving it in, if the code is changed in a way that that it doesn't produce NPEs for Bindable interfaces.
Chris -----Ursprüngliche Nachricht----- Von: Alex Harui [mailto:aha...@adobe.com] Gesendet: Montag, 3. November 2014 18:15 An: dev@flex.apache.org Betreff: Re: AW: AW: AW: AW: [FALCON] Bindable interfaces? On 11/2/14, 11:15 PM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: >M testcase consists of a bindable interface, a bindable class that >implements this and has one property as well as an Application, that >uses an instance of the class to write the content of a TextField into >the bindable variable and a label to be automatically updated if that >changes and all seems to be workin fine. > >If I read the code I removed: >This checks the current class if it is bindable or has a bindable >variable. If it has, it checks if the class has no super class. If it >doesn't it makes the class extend EventDispatcher and adds the import >statement to this. In any other case it doesn't do anything. I found >other parts of the code (The ones where you worked on Binding issues). >Here there are methods to calculate if a class needs to implement the >IEventDispatcher interface and to add the interface as well as its >implementation to the current class. So I am still assuming that >particuar code is obsolete. It could be that this code is needed for FalconJX. Or it might be a scenario I saw once where someone was calling addEventListener on the object. Git history shows that code was added by me in August 2013, so it has to be somehow related to FlexJS. Unfortunately I did not put more detail into the check-in notes. I guess next time I pull changes I’ll find out what broke if anything. -Alex
