[Laszlo-dev] Why does LzDelegate require its context to inherit from LzEventable?

[Neil Mix]

I do remember how the old LFC relied on silent errors.  It made my  
initial read of the source code unbelievably confusing until I  
realized that referencing non-existent objects was expected behavior.   
Kinda like nil in Objective-C, but not formalized.  But I digress.

When you say "either use a closure or add a method to the sender,"  
what does the closure option look like?  Let's say I want to listen  
for lz.Keys onkeydown events -- where would a closure fit into the  
event propagation scheme?  Do you just mean a dynamically created  
trampoline created in code versus a static trampoline defined in markup?

Also: is there a JavaScript syntax for creating a standard function/ 
class that extends an AS3 class such as Eventable?


On Oct 29, 2009, at 4:01 PM, P T Withington wrote:

> 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.