>
> I will reveal that what you propose is more or less possible with plain
> vanilla ecmascript 3. To modify your syntax proposal, what the syntax would
> look like is something like this:
>
> $(document).X(1,2).Y(3,4).Z("foo");
>
> this call returns an object, with a call, and an apply method (possibly a
> function object?) that when called, starts a chain of execution that is
> suspended at the finishing of each operand. Most of the time this suspension
> would be caused by a simple call to setTimeOut(next, 0); With other
> functions that are obviously asyncronous, such as XHR calls, the suspension
> is resumed at the point when the callback would normally be called.
>
> This would be made possible by a library, I will call MND for the purposes
> of this discussion. You start by passing MND an object with a set of
> related methods:
>
> var MyMonad = MND.make(MyObject);
>
> the MyMonad object has methods with all the same names as the object that
> you passed in, but when you call them, the names and arguments are simply
> placed on an internal stack, and an object with call/apply methods is
> returned.
>
What you've described is more or less a generalized version of what my
script loader LABjs does.
$LAB.script(...).script(...).wait(...).script(...).wait(...);
The internal code runs through the entire chain the first pass, and stores
all the calls, params, etc. It also (different from your general Monad
behavior) fires off a "preloading" of each parameter to a .script(). But
then, during the second asynchronous pass through the chain, it hops through
the queue/stack of calls one at a time, in the appropriate order, waiting
for each step to finish before proceeding.
Not that this discussion thread has anything at all to do with LABjs (or
script loading), but I just wanted to share that such a concept is in fact
valid and workable, and has been in LABjs for well over a year.
-------
I also have experimented with a similar concept in the promise/defer area,
with a chainable "Promise" implementation I did. It roughly looks like this:
X(1,2)
.then(Y) // Y called with no params
.then(function(){ Z("foo"); })
...
While this works (and I currently use it in some of my projects), it creates
a lot more awkwardness around "message passing", and even more complexity in
expressing/handling the "conditional" case where you have alternation
between a "success" or "failure" case.
For instance, I experimented with:
X(1,2)
.then(Y)
.else(Z);
When there's only one "then" condition and only one "else" condition, it's
not too bad. But, a key concept in the chainability of promises is something
like:
X(1,2)
.then(Y)
.then(Z)
.else(W)
.then(A)
.else(B)
.else(C)
...
With the use of a ternary type operator, and even ( ) grouping, it can
become clear where the pairings of then/else are, but with a linear chain
like this, it's much harder to decipher. Also, when I complicated my
"Promise" lib with "else" functionality, it got so much more complex that it
had some race conditions I never could solve.
I eventually sort of decided the effort wasn't worth it. And shortly
thereafter, in that frustration, my initial ideas for needing native syntax
to negotiate all this were born. It just took me awhile to publicly
formalize my proposal. :)
--Kyle
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
