F
fltcpt
After reading the many posts on the newsgroup,
I still disagree with the people who claim you
will never need a sleep(), or that a sleep()
is a bad idea, or that sleep() does not fit
in the event driven model, etc..
Fine, not sleep, but at least a blocking
function - that's whats missing in javascript,
and I bet that's what's most people looking for
sleep() had wanted.
A blocking function (like a wait() that
others have proposed) would dispatch events
but not proceed the script. Terrible idea? That's
what a prompt() or an alert() does, they block
the execution of the script while servicing
events and waiting for user inputs... but
a "wait()" like function will have custom
logic to get out of the loop instead of waiting
for a button click.
Why would I want to do this? Can't I do it with
setTimeout()? No. Consider I want to write a
reusable function that someone can just pick
up and use it:
function foohelper() {
// essentially the second part of foo
}
function foo() {
...
setTimeout('foohelper();');
}
The caller should be able to expect foo() to be
atomic and never interleaved with their code (bar)
foo();
bar();
Whenever I discuss this with others, the repsonse
that invariably comes back is "What are you trying to
do?" "Why would you care" (good indication that they
have no idea how to solve this). It's simple, I want
a function others can call and not having
1. me to worry about what others will do and
2. others worrying about what I have done.
What if foo() sets up some shared object that bar uses?
Say foo() loads an applet that creates a a window that
covers up the screen to act as some new wallpaper
background before bar() loads an applet that
puts up a dialog... if the order is reversed (that happens
when foo loads the applet dynamically), bar()'s
dialog is covered up by foo()'s... the thing is, I
should be able to, within foo(), block the execution
of the script by polling until my applet has fully
initialized... you may propose "why don't you load your
applet at <body onload=>" or "put bar() at a setTimeout"..
and if you do ask that, let me reiterate my point - that
I should not care how other people use my function, that
other people should be able to call it inline, call
in at onload, call it by doing a document.write('foo();')
or whatever which way, and it still works. Javascript
disallows that. That's why people want a sleep() (or a sleep
like function in fact, not exactly a thread blocking sleep()).
If you have actually read the whole thing (reasonably
carefully) and can come up with a solution (yes, I am aware
that you potentially have a wait() called by a wait() recursively,
but that's not a problem and why so is another topic) thanks,
I'd like to know about it, and yeah, I'll take back everything
I've just said
If not, thank you for agreeing with me
I still disagree with the people who claim you
will never need a sleep(), or that a sleep()
is a bad idea, or that sleep() does not fit
in the event driven model, etc..
Fine, not sleep, but at least a blocking
function - that's whats missing in javascript,
and I bet that's what's most people looking for
sleep() had wanted.
A blocking function (like a wait() that
others have proposed) would dispatch events
but not proceed the script. Terrible idea? That's
what a prompt() or an alert() does, they block
the execution of the script while servicing
events and waiting for user inputs... but
a "wait()" like function will have custom
logic to get out of the loop instead of waiting
for a button click.
Why would I want to do this? Can't I do it with
setTimeout()? No. Consider I want to write a
reusable function that someone can just pick
up and use it:
function foohelper() {
// essentially the second part of foo
}
function foo() {
...
setTimeout('foohelper();');
}
The caller should be able to expect foo() to be
atomic and never interleaved with their code (bar)
foo();
bar();
Whenever I discuss this with others, the repsonse
that invariably comes back is "What are you trying to
do?" "Why would you care" (good indication that they
have no idea how to solve this). It's simple, I want
a function others can call and not having
1. me to worry about what others will do and
2. others worrying about what I have done.
What if foo() sets up some shared object that bar uses?
Say foo() loads an applet that creates a a window that
covers up the screen to act as some new wallpaper
background before bar() loads an applet that
puts up a dialog... if the order is reversed (that happens
when foo loads the applet dynamically), bar()'s
dialog is covered up by foo()'s... the thing is, I
should be able to, within foo(), block the execution
of the script by polling until my applet has fully
initialized... you may propose "why don't you load your
applet at <body onload=>" or "put bar() at a setTimeout"..
and if you do ask that, let me reiterate my point - that
I should not care how other people use my function, that
other people should be able to call it inline, call
in at onload, call it by doing a document.write('foo();')
or whatever which way, and it still works. Javascript
disallows that. That's why people want a sleep() (or a sleep
like function in fact, not exactly a thread blocking sleep()).
If you have actually read the whole thing (reasonably
carefully) and can come up with a solution (yes, I am aware
that you potentially have a wait() called by a wait() recursively,
but that's not a problem and why so is another topic) thanks,
I'd like to know about it, and yeah, I'll take back everything
I've just said
If not, thank you for agreeing with me