On 12/1/05, P T Withington <[EMAIL PROTECTED]> wrote:
I think closures provide a different kind capability than delegates/events -- there's nothing quite like an anonymous function with it's free variables bound for saying what you want right there where you want to say it in the code, with all the environment saved for you.
I also had an epiphany about trying to design classes which can be both scriptable and also used in LZX code as components; In the words of Nancy Reagan, "just say no". Use two separate classes instead.
Someone sent in a test case which contained a set of LZX classes to define context menus, and they internally called the Flash ContextMenu classes. I realized that is probably the right paradigm; have two separate sets of classes - an underlying 'scriptable" set which have a scripty API, and then a separate set of LZX classes, which are designed to call
the script API classes or functions, but are free to be designed only for "LZX" usage. That means you don't have to worry about making a single class which is both easy to use from _javascript_, but also properly handles your init args, constructor functions, event handlers, etc that need to be done in LZX code.
Closures and delegates are isomorphic, except that in the current
(swf8 and previous) player, closures don't close over `this`, which
is why we need delegates. In swf9, this is fixed. We could make
delegates be closures, that we 'fix up'. Last time I measured
though, closures were space-inefficient compared to delegates.
Perhaps this has been fixed in more modern players. (I'm guessing
that in old players, closures may have hung on to their entire
environment, rather than just the particular value-cells they closed
over.) [There is also, in the current compiler, still vestiges of
the kludge to make functions execute in the correct context, which
can break some closures. We'd need to root this out if we made
delegates be closures.]
As to callback vs. event, the whole rest of LZX is event-based, so I
wonder why you would introduce callbacks? (Have I mentioned how much
I hate Perl lately?)
I think closures provide a different kind capability than delegates/events -- there's nothing quite like an anonymous function with it's free variables bound for saying what you want right there where you want to say it in the code, with all the environment saved for you.
I also had an epiphany about trying to design classes which can be both scriptable and also used in LZX code as components; In the words of Nancy Reagan, "just say no". Use two separate classes instead.
Someone sent in a test case which contained a set of LZX classes to define context menus, and they internally called the Flash ContextMenu classes. I realized that is probably the right paradigm; have two separate sets of classes - an underlying 'scriptable" set which have a scripty API, and then a separate set of LZX classes, which are designed to call
the script API classes or functions, but are free to be designed only for "LZX" usage. That means you don't have to worry about making a single class which is both easy to use from _javascript_, but also properly handles your init args, constructor functions, event handlers, etc that need to be done in LZX code.
_______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
