On 2009-10-29, at 16:40, Neil Mix wrote:
I understand why event senders would needs to be LzEventable, but why event receivers?
Mostly this was because we had to rationalize the way events were propagated when instances were created and constraints fired. It turned out that a lot of that worked only 'by luck' in swf8 (with the helpful feature that swf8 graciously ignored any errors like calls to non-functions, evaluations of non-existent variables, etc.) When we created the DHTML and swf9/10 back-ends, they were not so forgiving. LzEventable encompasses the protocols that allow an orderly evaluation of constraints.
It's not done yet, but this also was to reduce the need to manually manage delegates. Delegates are a constant source of memory leaks because they get forgotten and can end up "resurrecting" objects that should have been collected. So, in swf8 and DHTML, we now warn you, but in swf9/10 you will get a type error. Eventually, we hope to be able to manage delegates completely internally to LZX.
Related: is there any way to trick the AS3 runtime into accepting a dynamic POJSO as an LzEventable?
Usually when people run into this issue updating their code, they can either use a closure or add a method to the sender that trampolines to the non-LzEventable.
If you have a particular example, I can comment further.
