I worry about the inconsistency of having closured function
"pointers" available in one API but not in others -- asymmetry of
APIs is painful, painful, painful. (I'm constantly tripped up in the
Laszlo API trying to remember if some value is available via an
attribute, property, or getter method.) I think it would be great to
make closures an option in addition to delegates across the *entire*
Laszlo API. (For example, by implementing the LzDelegate methods on
the Function.prototype object.) If that's not practical, then
sticking to delegates only would be best, IMHO.
off-topic: P.T., if I understand you correctly, in swf9 the "this"
that is present when a function is defined is what gets used when the
function is executed? I've never seen a browser JavaScript
implementation do that -- it seems that would break the language in
some pretty fundamental ways.
On Dec 1, 2005, at 7:50 AM, P T Withington wrote:
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?)
On 1 Dec 2005, at 01:21, Henry Minsky wrote:
So, I have been oscillating back and forth over what kind of
callback API to
support for the right-click menu API.
The problem is as follows:
The user wants to specify what should happen when a menu item is
clicked on.
Do they pass in a function (closure) that gets called? Does the
menu item
object
get a "onselect" event sent to it? Does the user pass in a
LzDelegate to get
called back?
I could not decide which mechanism to support, and after going
back and
forth a few times , I decided to
support all three. So in my current API implementation, when
setting the
callback, the menu and menuitem classes accept either a function,
or an
LzDelegate for the callback, and they also send a "onselect" event to
themselves.
This seems like the right thing to do and also the wrong thing to
do, I'm
not sure which.
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
