Unfortunately for me, i don't offer much on the deeply technical side,
but want to offer my vote to explore this idea. The self-stop is
definitely an attractive feature, and while the examples that i've
seen in this thread show a stop-on-return-false, it would probably be
more correct to stop-on-provided-condition:
[snipped from Robert's post]
Object.extend(Function.prototype, {
repeat: function(delay, stopCondition) {
this.stopCondition = typeof stopCondition == "function" ?
stopCondition : function(test){return test ===
stopCondition;}; // or $break-like mechanism?
...
if (!this._repeater) this._repeater = function() {
// Let _method cancel repeat by testing against stopCondition
if (!this.stopCondition(_method())) setTimeout
(_method._repeater, delay);
}
...
[/snip]
i'm obviously no expert. Robert mentions not being a fan of argument
interpretation, which makes sense. But in this case, the only
"exception" is for a function, and only occurs when the repeat is
created. And one strike against the above is if the user provides a
time-consuming stopCondition function, it increases the time to the
next repeat. Unless some timing math is done on either side of the
stopCondition call to balance the setTimeout delay:
setTimeout(_method._repeater, delay - (timeAfterStopCondition -
timeBeforeStopCondition));
...which is bad when the time differential is > delay. :(
For what it's worth, i'd like to see allowance of any object type to
be the stop condition, but if there are greater issues preventing
that, i defer to the better judgment of the developers. :)
-joe t.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~----------~----~----~----~------~----~------~--~---
