[Sorry for the delay in replying -- deep in a project here.]
On 2009-10-29, at 17:48, Neil Mix wrote:
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?
I was just pointing out that method closures actually work in AS3, so
if you are talking to a native AS3 interface and need a callback, you
can just pass the method, you do not need to build any complex
mechanism to use a delegate for your callback.
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?
Henry has already pointed you in the right direction on this I think.
The OpenLaszlo script compiler supports most of (what was to be) JS2
syntax for classes. So you could write (untested):
/* Class to trampoline OL events to closures/callbacks */
class EventListener extends LzEventable {
var callback:Function;
var delegate:LzDelegate;
function KeyListener(callback:Function, eventSender:LzEventable,
eventName:String) {
this.callback = callback;
this.delegate = new LzDelegate(this, 'onevent', eventSender,
eventName);
}
function onevent(event):void { this.callback.call(event); }
function destroy() {
this.delegate.unregisterAll();
super.destroy();
}
}
/* Example callback */
function handleKey(key) { ... };
/* Install a listener that will call the callback */
var myListener = new EventListener(handleKey, lz.Keys, 'onkeydown');
[Note the destroy method, necessary to prevent leaks if you need to
dynamically create and dispose of listener objects. If you don't call
destroy, the delegate will keep the closure alive as long as the
sender is alive.]
Hm, maybe we should just add something like this to the LFC, to extend
events to closures? Seems like a generally useful feature.
But also, you can fairly cheaply write something similar in LZX. A
<node> is an LzEventable, and is fairly lightweight. It doesn't
create any graphical elements. So you could also say:
<node>
<handler name='onkeydown' reference="lz.Keys">
...
</handler>
</node>
You could put any number of handlers into a single node.
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.
