On Dec 1, 2005, at 10:43 AM, Neil Mix wrote:
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.
Agreed. Let's stick with delegates, and add closures across the
board or not at all. If closures are an option for some APIs and not
others, the convenience where they can be used will be outweighed by
the inconvenience of trying to remember where you're allowed to use
them.
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.
Right again. It doesn't matter what swf9 supports so long as we're
supporting swf7 and swf8 and adding support for browser js.
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
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
