Andrew Kluthe wrote:
1. Livecode messaging is fully asynchronous. Not semi-async.
Right, when I said semi-async I was referring to the single threadedness of
livecode (which node shares) along with all the baked into livecode stuff
that blocks up messages currently: accessing a large file on disk, posting
some information to a web service with a large json payload being returned.
It's async, with some pretty hard to work around exceptions (url library
specifically has been the primary source of past frustration in this way).
3. Livecode does not have closures = passing anonymous callbacks as
params to functions so they can be executed later
As for anonymous callbacks, I totally agree. Most early Node development
had to overcome the callback hell that these patterns introduce. However,
almost all of the nodejs projects and libraries I've worked with leveraged
them heavily or exclusively. Promsies seem to have become the standard way
of dealing with the callback hell that node was so famous for for a long
time. Why does node use anonymous functions over the method you linked to
in the article? Anonymous functions are marked for garbage collection
immediately after being returned. All other functions at the global scope
run the risk of needlessly using memory after they run. I've gotten into
some hairy situations with memory management with these kinds of named
callbacks (specifically for database access and return of lots of results
when not scoped correctly).
Passing a function (not just a name of a function to be used with a send or
a dispatch later on) as a parameter even in your article still demonstrates
something LC just can't do currently. In the article he's still using
closures, it's just got a name instead of being anonymous. It's still a
closure. LC has ways to accomplish similar things by passing names of
functions and using dispatch, but I think it's not exactly the same.
Closures are part of the reason node.js works the way it does and closures
are one of the pirmary reasons javascript was chosen for node. It's
certainly possible to do async without them, but closures are what makes it
easy and kind of a fundamental principle to working in node.js.
4. But we can easily call / dispatch calls to functions by passing names
around and we can limit scope by using private handlers or libraries.
Sure, there is nothing STOPPING us from implementing named callbacks in the
current fashion or passing the named callback references dynamically as you
and I mentioned, but from experience trying it this way I feel like it
makes maintaining large projects built this way a lot more difficult. To
the point where I ended up completely redoing most of the livecode stuff
I've written in this way early on because it was getting to be a nightmare
to maintain a completely separate callback functions rather than the sort
of nested structure you get in node with callbacks. It takes a lot of
discipline in placement and grouping of the code that is related in this
way to come back later and make sense of it. In summary: it can be done,
but that doesn't mean that it SHOULD be done.
Kind of a weird long post there. Sorry for the length and probable
repetition of my points.
Not at all - good stuff.
What would you say would be the minimum we'd need to add to the LC
engine to make it suitable for the sort of work you do?
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
