Hi all,
Weighing in... First off, love the idea of Function#repeat.
Wonderfully simple and expressive.
As Tobie says, the goals when doing it should be to handle all of the
issues PE already handles, to reuse existing code, and to be
consistent with other API functions.
Some notes:
1. I'd avoid requiring #curry or #bind on top of #repeat; #repeat
should be able to handle arguments and context itself. Every curry at
least doubles the call overhead.
2. Optional context would be helpful:
Function#delay(options[, args...]) -> Number
...with `options` being either a number (frequency) or an object with
`context` and `frequency` parameters; the latter allows repeating
method calls.
3. #1 suggests that rather than #repeat using PE, the guts of PE
should become #repeat and the PE should use it:
var PeriodicalExecuter = Class.create({
initialize: function(callback, frequency) {
this.handle = callback.repeat(frequency, this);
},
stop: function() {
if (this.handle) {
clearInterval(this.handle);
this.handle = 0;
}
}
});
4. I'd like to be able to repeat functions not explicitly designed to
#repeat, which suggests not changing their signature. Perhaps the self-
stop mechanism could remain a feature that PE adds on top of #repeat
(at the cost that PE functions have to be explicitly intended to be
repeated [or must ignore their args], as is currently the case).
5. Like Robert, I prefer the self-repeat over setInterval (that's
always how I do it), but unless we've seen significant issues with
setInterval we should be wary of changing it, especially in light of
how doing so complicates the API (e.g., return value issues). Perhaps
this aspect is a separate question entirely.
6. If we do need to use something other than an interval handle as the
return value, I'd suggest providing a stop function that works with
both interval handles and whatever our new thing is, e.g.:
Function.stop = function(handle) {
if (typeof handle == 'number') {
clearInterval(handle);
}
else {
/* ...stop it the new way... */
}
};
@Rick: All of this discussion probably seems like nit-picking your
idea to death. In fact, I think it indicates that there's a lot of
support and appreciation for your idea, and we're all (well, nearly
all, there's a dissenter) just trying to make it fit in, and make it
as cool as the idea warrants.
--
T.J. Crowder
tj / crowder software / com
On Aug 26, 3:33 am, Samuel Lebeau <samuel.leb...@gmail.com> wrote:
> Joe,
>
> Callback function receives PE instance as first argument, so here
> would be the self-stop mechanism :
>
> function(executer) { executer.stop() }.repeat()
>
> Best,
> Samuel.
>
> On 26 juin 09, at 15:46, joe t. wrote:
>
>
>
>
>
> > Tobie,
> >> Function.prototype.repeat = function(interval) {
> >> var fn = this;
> >> if (arguments.length > 1) {
> >> // not testsed but you get the idea
> >> fn = fn.curry.apply(fn, Array.prototype.slice.call(arguments, 1));
> >> }
> >> return new PeriodicalExecuter(fn, interval);
>
> >> }
>
> > If sticking to the PE approach there's no internal self-stop mechanism
> > (is there?), which i see as a nice touch in the above proposal (for
> > what my opinion is worth).
> > What about (from 1.6.1_rc2):
>
> > onTimerEvent: function() {
> > if (!this.currentlyExecuting) {
> > try {
> > this.currentlyExecuting = true;
> > if (this.execute()===false) // MOD
> > this.stop(); // NEW
> > } catch(e) {
> > /* empty catch for clients that don't support try/finally */
> > }
> > finally {
> > this.currentlyExecuting = false;
> > }
> > }
> > }
>
> > Just tossing in my 2 cents because i'm intrigued by that feature.
> > -joe t.
>
> > On Jun 26, 6:02 am, Tobie Langel <tobie.lan...@gmail.com> wrote:
> >>> How to stop it? arguments?
>
> >> Stopping it is as easy as:
>
> >> pe = foo.repeat();
> >> pe.stop();
>
> >> Passing arguments would require some simple currying:
>
> >> Function.prototype.repeat = function(interval) {
> >> var fn = this;
> >> if (arguments.length > 1) {
> >> // not testsed but you get the idea
> >> fn = fn.curry.apply(fn, Array.prototype.slice.call(arguments, 1));
> >> }
> >> return new PeriodicalExecuter(fn, interval);
>
> >> }
> >>> This may come to you twice, but this is slightly updated:
>
> >>>http://jsbin.com/opimu
>
> >>> This repeat() method def is 775Bytes, accepts arguments like delay/
> >>> defer,
> >>> uses setTimeout (returns initial setTimeout index) and has a
> >>> stopping
> >>> mechanism.
>
> >> What's the point in returning setTimeout index? That will set
> >> expectations which can't be met: developers will expect to be able to
> >> stop the functions calls by clearing it.
>
> >> Are you sure your proposal fixes all of the small issues PE fixes?
> >> For
> >> example, does it guarantee that the function will continue being
> >> called if it happens to once throw an error. Does it avoid calling
> >> the
> >> function again if a previous function is still executing, etc.?
>
> >> I understand your eagerness to move away from a model you dislike,
> >> but
> >> that shouldn't make you throw away all of the work that's been put
> >> into previous solutions.
>
> >> FWIW, I just noticed a patch wasn't applied to PE in current trunk
> >> (it's missing a throw statement).
>
> >> Best,
>
> >> Tobie
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
