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. Chris -----Ursprüngliche Nachricht----- Von: Alex Harui [mailto:aha...@adobe.com] Gesendet: Montag, 3. November 2014 06:29 An: dev@flex.apache.org Betreff: Re: AW: AW: AW: [FALCON] Bindable interfaces? I’m going to try to consolidate your last set of emails into this post. On 11/2/14, 12:45 PM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: >Even if I could not 100% confirm the code was doing the same as >compared to the default compiler. I could confirm that removing the >code I was thinking of being redundant didn't have any effect on the >generated output. The classes abc code were identical. So I guess it's >safe to assume, that removing the code doen't break anything. I’m concerned that removing that code is going to break some scenario involving binding to a bindable class. Maybe Darrell or Gordon can provide more information, but the code you are removing is in handleSyntaxTreeRequest, and the code you are relying on is part of handleABCBytesRequest. I think handleSyntaxTreeRequest is called when some other class is trying to reference members of the class being compiled, and handleABCBytesRequest is called to output the ABC to the SWF/SWC. Did your scenario have some other class call addEventListener on the class being compiled, or bind to the class being compiled? > >Ok ... so I found out what the first two commands are: > >get "this" and make it the scope ... makes sense to have this in every >non-static function, but why is this missing in falcon? > >Every function call in the default compiler results in these two lines >of >code: > > 0 getlocal0 > 1 pushscope > >these are missing in Falcon compiled code. I don’t know for sure. It could be that, with strict mode, you don’t need scope in certain scenarios. Again, maybe Darrell or Gordon can answer. > >Another change I found was that in Falcon compiled code the Metadata is >kept at class level while the default compiler moves the metadata to >the property. Ist this of any significance? I could immagine that if I >have a class extending a falcon compiled class then all properties in >this extension would be bindable too, if extending a default compiler >compiled class I would only expect the properties of the base class >bindable. But that's just wild guessing ... reading ABC code is >something I'm not really familiar with. That could be a bug. Again we’ll need to find a test case that exploits it. >But ignoring the first two statements (even a one-line return null >function had these). The results were semantically allmost identical. >Only the setter of a Bindable variable were slightly differntly >implemented and the private variable didn't have the number prefix ... >don't know if this could be a problem: > >private var tst:String; > >public function set tst(val:String):void { ... >} > >pubic function get tst():String { >... >} In theory, the private var is actually in a namespace. -Alex
